gbadev.org forum archive

What do you think?

Don't get me wrong. videoGL is on top of my favorite things about libnds... it introduced us to OpenGL on DS development (something that, IIRC, the official N tools doesn't even have :| ). And, for the most part, it does wonderfully.

The thing is, although videoGL follows in many aspects the OpenGL standard, it's not a close match to it. Matrix handling, textures, lights, (some) color mappings, and the many extra functionality that the DS has that OpenGL does not. Again, this is not bad; it's just not-compliant OpenGL.

What I'm basically thinking is that, if we can provide developers with an externally linkable OpenGL library, ***in addition to videoGL, not replacing it***, it should make things easier to understand for us devvers that know enough of OpenGL to feel comfortable using it. I know it would for me. Do you?

- Izhido

Ooh, I'm in two minds about this!

On the one hand I'd say no, people are gonna eventually have to move their stuff over to the 'real' GL solution (ie using fixed-point, special data types etc). That means loads of work is gonna have to be put into devloping a library which will eventually be redundant. When people realise they should be using the faster solution, the compliant GL will stop being developed and will get code rot etc...

But on the flip side, a proper GL would be great for me as porting code would be oh so much easier!

Where's the 'I'd vote for both' option?!

Oh and I was about to make a poll (about something else) - if I add one now it looks like I'm gonna be copying you!
_________________
Big thanks to everyone who donated for Quake2

I would say do one of two things (or both :) ...

1/ put your effort into helping to improve videoGL.

2/ create a true replacement, _if_ it can be done with more compatibility and only minimal additional overhead.

I'd avoid co-existing APIs as you'll split effort and knowledge between the two camps. Worse still, the terminology is shared causing problems in terms of documentation and community help.

I suspect that if you work on option 1 then you'll be able to establish the viability of option 2. Maybe you have already?

I'm not saying don't do it (although it may sound like it), I'm saying try your best not to divide the community. Keep the project low-key until it's ready to fully replace, and avoid any long period of co-existence.

Other things that would help,

- More tutorials and examples to help those used to compliant GL get used to videoGL.

- A code analyser (to run on the to-be-ported compliant code) that points out likely porting issues.

Well I believe, if it's in addiction to videoGL as you said before, then what's the harm. People can use either one they want and choice is never a bad thing :)

Would a useful subset of OpenGL ES be more useful? It supports fixed point data types.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

OpenGL ES really isn't a great fit to the DS hardware;
- fixed point is 16bit decimal instead of 12bit
- still has triangle fans, the DS can't do fans
- matrix column/rows are still backwards to DS
but I do like the naming conventions, postfixing fixed-point functions with an x is something you will likely see soon in videoGL.

Personally I'd prefer a higher-level 3d library/framework. I know of palib, but the last 2 times I tried it, none of the 3d examples worked on hardware.

I don't want to have to fiddle with polygons and display lists and matrixes. I want some classes like:

Code:

// handles basic stuff like adding objects to the scene, rendering
// the scene to hardware
class Scene3D {
public addChild(Object3D child);
public render();
}

// most basic object
class Object3D {
public int x,y,z;
public int xRot,yRot,zRot;

// load geometry & textures from a datafile
// perhaps Collada? it's sort of a standard, most things can export to it
public bool loadModel(u8 *modelData);
}

// this class supports 3d objects with animations
class AnimatedObject3D extends Object3D {
public void gotoFrame(int frame);
}

// and some graphics primitives
class Cube extends Object3D;
class Sphere extends Object3D;
class Plane extends Object3D;

1) GL is a floating point standard. A subset of ES might be okay
2) GL has about a billion things in it, much of which the DS has no hardware support for. The cpu/memory bus is not equiped to make up for much of it in software.
3) I wrote the gl wrapper to make starting out on DS familiar but I would hate to see libnds have its hands tied by a standard which is out of sync with the hardware.

I do agree much could be added with minimal overhead to make the library more open gl compliant and just plain better (the stuff gbabear is doing for instance is great).

There is much room for improvement in the library but the DS cpu is just too slow and memory too tight to make too many sacrifies in efficiency for the sake of a complient opengl wrapper.

As to a higher level 3D library that is probably not going to be a goal of libnds. Perhaps we will see more third party library contributions which will fill these gaps (PAlib for instance although I would prefer it if were packaged as an addon instead of a replacement for libnds)
_________________
www.drunkencoders.com

The main problem with videogl.h seems to be that functions that are named with the gl prefix don't always work exactly like OpenGL functions. I purpose the following solution:

Break the videogl library across:

This way gl functions that are implemented should work exactly like you expect. The dsgl.h file will be included with nds.h the same way videoGL.h is currently included, but the gl.h will have to be included explicitly. Not including gl.h by default will keep people from accidentally using non-optimal implementations.

I couldn't agree more with you, gabebear! I think this is the way to go. I support your proposal :) .

- Izhido

gabebear wrote:

Not including gl.h by default will keep people from accidentally using non-optimal implementations.

I'd suggest also sticking a #WARNING in gl.h pointing out that it's non-optimal. Then those using cut'n'paste code will still get some indication.

I approve this. That way the dsGL interface can be set free from conforming to GL standards in ways that do not make optimal use of the DS hardware or go against them completly (maybe it should even be renamed to something else other than dsGL to clear any future confusion?); and the OpenGL interface can be as compliant as possible without worrying too much about performance and assume a role as learning/stopgap tool.

It sounds like a win/win situation.

i voted no, though i'm an opengl minded being. for my reasons check out the other posts, as i don't want to repeat others. (short: we need specialisation on such a limited and specialized device like the nds!)

Do you guys know how much work writing a full OpenGL implementation is? Not to mention the lack of features in the DS-GPU... It's not even able to do a standard-compliant OpenGL ES 1.0 implementation. Improving VideoGL to be more OpenGL-alike is another thing. But do not ever believe the DS will be OpenGL compliant in any other sense than having a similar API (which is not OpenGL compliance by itself).

On the other hand, not having direct source level OpenGL-compatibility prevents people from believing their Desktop OpenGL-code will work on DS, and will make you aware of the importance to adopt the DS-specific features (like the command fifo) for performance.

gabebear wrote:

- matrix column/rows are still backwards to DS

Since when is state-storage (or rather - perceived state storage) related to hardware formats?

IMHO trying to force a standards-compliant OpenGL onto the DS hardware is like trying to shove a triangle in circle hole.

I would prefer to have the API custom made for the hardware it is supporting, that my take.

kusma wrote:

On the other hand, not having direct source level OpenGL-compatibility prevents people from believing their Desktop OpenGL-code will work on DS, and will make you aware of the importance to adopt the DS-specific features (like the command fifo) for performance.

This is a double-edged sword. Major incompatibility with OpenGL means newbies won't simply copy and paste their unoptimized resource-hungry code that works on their nice powerful desktop and wonder why it doesn't work on the DS, but it also means experienced users will need to do extra work to port their code when cross-developing for multiple platforms or prototyping on a desktop OS.

I'd say make it as similar to OpenGL as possible without trading performance for source-level compatibility, but make it clear that the DS is NOT OpenGL compliant and some things will be different.
_________________
I'm a PSP hacker now, but I still <3 DS.

exactly! also, porting already means a lot of work, so all that can be done is to reduce this workload by providing a low level api similar to opengl. there will never be some hybrid code that compiles for the nds as well as some other platform, alone because of the lack of a floating point unit.

making ports easier is the right way and i think libnds is already doing a good job!

I think calling it GL is a bad move to begin with. I think Nintendo has a habit to prefixing their graphics libraries with gx, like the gamecube stuff here:

http://gc-linux.cvs.sourceforge.net/gc-linux/libgx/include/gx.h?view=markup

And the reason it would be good not to call it GL or OpenGL is that I see a lot of people here confused about it and trying to learn from the real OpenGL tutorials and samples--and too often failing miserably :).

Either make it OpenGL-compliant, or replace all the OpenGL-like functionnames with something more platform-specific.
Because right now, it's obviously confusing to some.
_________________
http://licklick.wordpress.com

Lick wrote:

Either make it OpenGL-compliant, or replace all the OpenGL-like functionnames with something more platform-specific.
Because right now, it's obviously confusing to some.

Yeah, and making it OpenGL-compliant to a degree where you won't have boat-loads of forum-threads like "HELP! MY glBegin(GL_POLYGON) CODE DOESNT WORK", "IS GL_ARB_SHADOW_MAPPING ON DS BROKEN" etc is way too much work. (I should know, I work as an OpenGL ES driver developer - and we see that even very experienced coders make the stupidest assumptions on equalence between apis when doing cross-API stuff at source-level)

I would much rather wrap these kinds of things up myself if i need portability anyway.

All right, then.
At the time of this post, the poll is at Yes: 24, No: 14, ??: 4.

This, even in spite of all contributions to this thread going against the standards-compliant lib.

Well, that does it! If everything goes ok, I think I'm starting to build the aforementioned library (libGL). This library should work **along with** libnds to provide a standards-compliant OpenGL interface to the DS. Also, while I'm at it, I should create his two usual companions, libGLU & libGLUT.

Wish me luck!

- Izhido

Izhido wrote:

Wish me luck!

Good luck. Start by defining what parts of the OpenGL API is most vital, and realize you'll most likely never be finished with a complete OpenGL implementation. Just make sure the most important parts work, and that they work like specified :)

(Look forward to the joys of texture name lookups etc ;)

Izhido, i also wish you good luck.

your opengl implementation could be a good way for prototyping, but final "products" (not speaking of commercial items) should be build ontop a very thin library layer that is very close to the hardware. that's my opinion.

speaking of function prefixes: it's damn right that naming stuff according to opengls names is a bit off. using it's naming conventios is ok, though. it's overkill to set up all those functions with lots of "unused" parameters, just to artificially make it look like opengl, although these functions work differently and need different (and mostly less) data.
... and then comes all the confusion about data types, especially floating points.

Bad news, guys. I just dropped work on my initial attempt to OpenGL compatibility code.

I just recently realized what everything has been telling me all this time: a standards-compliant OpenGL layer would not be useful with the current 3D hardware in the DS. The device, simultaneously, does AND does **not** do many things I didn't imagine at first. Alpha-per-vertex, spotlights, matrix querying, stencil/accum buffers, direct framebuffer access, these among the things it does not do. Polygon IDs, per-primitive antialiasing, cel-animation, shininess table, translucent primitives, automatic depth sorting, and I'm sure ***many more***, are among the ones that it does.

My current knowledge of OpenGL simply can't cope with the differences.

I'll have to assume that, as of now, videoGL functions, even if they have the same name as some GL functions, they do **not** have the same effect as their counterpart GL ones. However, they do A LOT MORE than OpenGL can do, so it's probably better to stick to what libnds offers us for the time being.

Now, if somebody else is actually interested on continuing the project, I posted a .zip containing the source code of what I was working on until today (april 13, 2007) at http://www.costarricense.cr/pagina/izhido/Data/libGL.13.apr.2007.zip.
No strings attached. Take it & use it for what you need (or want). It **should** work; a copy of the hello.c GLUT program (from the Red Book) is included, if you want to test it.

- Izhido

You got a lot further than I thought you would, and you realized the problem a lot sooner than I thought you would. You beat my expectations twice. That's not common.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]

I'm a big fan of supporting OpenGL on the NDS - but 'standards compliant' simply isn't going to happen without you porting something like Mesa to the DS and doing all of the rendering in software.

Thinks like the hard cap on the number of polygons you can draw and the horribly limited numeric ranges for things like vertex coordinates means that hardly any pre-existing OpenGL programs stand a chance in hell of running on the DS without a lot of work. Given that you have to do a lot of work anyway - the effort level to deal with the non-standard things is almost negligable.

I would like for the existing functions to work better - no sneaky backdoor mode changes and careful and explicit documentation on the limits that are expected of input parameters.

But attempting (and failing by a million miles) to make a standards-compliant OpenGL is a waste of time and an exercise in futility.

(Incidentally - the reason the poll is going "Yes" when all of the posts are saying "No" is simply because people who have no clue that this is in fact completely impossible are answering "Yes" because it sounds like a great thing to have. If we COULD have it - then I'd vote "Yes" too - but it's quite utterly impossible to come within a million miles of doing this - so my "No" vote is more "No, don't waste your time on a fruitless effort" than it is a "No, I really don't want this"....sure I'd like it - but it's pointless because the hardware lacks some really fundamental things that you can't do without if you want true compliance.)

Perhaps there should be a library another way around: For compiling OpenGL apps on Win32 / Linux / OSX using "NDS only" hardware 3d capabilities. :)

Don't know how people here are generally dealing their project development but it's always easiest in the long run to get things working also on the source / compiler platform.

Indeed. I used empty Win32 versions of the PSP SDK functions I was using to track down a bug in PSP Quake. Worked like a charm.
_________________
http://aaiiee.wordpress.com/

Who is this 3dgeek guy, and why is he broad-brushing possibility so hard? 3dGeek: you don't need Mesa to implement OpenGL in software, and implementing the OpenGL 1 or OpenGL Mobile profile is something you could do with significant spare processor time.
_________________
Quidquid Latine dictum sit, altum Sonatur
[Images not permitted - Click here to view it]

Well, he is being negative, but he's got a good point.

Desktop OpenGL is a nightmare to write a fast (hardware accelerated) standards compliant implementation of.

But maybe a non-standards compliant OpenGL ES work-a-like would be a bit more attainable. As Izhido says, the DS is missing some features which are required for compliance, but if the user doesn't try to use them, then it may be good enough.
_________________
http://aaiiee.wordpress.com/

PeterM wrote:

(...) But maybe a non-standards compliant OpenGL ES work-a-like would be a bit more attainable. As Izhido says, the DS is missing some features which are required for compliance, but if the user doesn't try to use them, then it may be good enough.

There already exists such a workalike: videoGL, part of libnds. It got **a lot** better since I started working on my lib... maybe you should check it out :D

But I seem to remember reading that there are holes in the capabilities exposed by videoGL, such as texture swapping.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

gbadev.org forum archive

DS development > Would a standards-compliant OpenGL library be useful for DS?

#119435 - Izhido - Thu Feb 22, 2007 11:29 pm

#119436 - simonjhall - Thu Feb 22, 2007 11:45 pm

#119448 - Tantrum - Fri Feb 23, 2007 1:50 am

#119450 - Rajveer - Fri Feb 23, 2007 1:59 am

#119454 - tepples - Fri Feb 23, 2007 2:31 am

#119462 - gabebear - Fri Feb 23, 2007 5:47 am

#119497 - josath - Fri Feb 23, 2007 6:17 pm

#119503 - dovoto - Fri Feb 23, 2007 7:18 pm

#119510 - gabebear - Fri Feb 23, 2007 10:03 pm

#119511 - Izhido - Fri Feb 23, 2007 10:08 pm

#119537 - Tantrum - Sat Feb 24, 2007 1:48 am

#119624 - M3d10n - Sat Feb 24, 2007 9:26 pm

#119925 - silent_code - Tue Feb 27, 2007 3:16 pm

#119928 - kusma - Tue Feb 27, 2007 3:34 pm

#119930 - kusma - Tue Feb 27, 2007 3:37 pm

#119941 - Goosey - Tue Feb 27, 2007 8:20 pm

#119979 - HyperHacker - Wed Feb 28, 2007 1:16 am

#120026 - silent_code - Wed Feb 28, 2007 12:59 pm

#120039 - memoni - Wed Feb 28, 2007 3:29 pm

#120046 - Lick - Wed Feb 28, 2007 4:07 pm

#120047 - kusma - Wed Feb 28, 2007 4:13 pm

#120053 - Izhido - Wed Feb 28, 2007 4:40 pm

#120054 - kusma - Wed Feb 28, 2007 4:47 pm

#120715 - silent_code - Mon Mar 05, 2007 7:26 pm

#125475 - Izhido - Fri Apr 13, 2007 7:06 pm

#125478 - StoneCypher - Fri Apr 13, 2007 7:16 pm

#125913 - 3D_geek - Wed Apr 18, 2007 5:20 am

#125914 - 3D_geek - Wed Apr 18, 2007 5:26 am

#125918 - melw - Wed Apr 18, 2007 7:38 am

#125923 - PeterM - Wed Apr 18, 2007 8:38 am

#125962 - StoneCypher - Wed Apr 18, 2007 4:31 pm

#125964 - PeterM - Wed Apr 18, 2007 4:49 pm

#125965 - Izhido - Wed Apr 18, 2007 4:58 pm

#125971 - tepples - Wed Apr 18, 2007 6:17 pm