GP2X Vincent Opengl Es 1.1 Implementation

[MiniMoose]

I just stumbled on Vincent and I think it is going to be a better candidate for a 3D library on the GP2X. It is actually trying to be standards compliant and it is being optimized for the ARM architecture.

If you offload sound, AI, input, I/O to the 940 and then dedicate the 920 to graphics, you could probably put Vincent to good use.

I think getting Vincent up and running on the GP2X may be my first project.

 

[darkplayer]

go for it!

 

[icurafu]

vincent is a good option. But it is designed for OPENGL ES hardware.

Klimpt is designed ground up for OpenGL ES software.

Mesa is another option for openGL software, but I understand it is slow as hell.

 

[BattleCattle]

I just stumbled on Vincent and I think it is going to be a better candidate for a 3D library on the GP2X. It is actually trying to be standards compliant and it is being optimized for the ARM architecture.

If you offload sound, AI, input, I/O to the 940 and then dedicate the 920 to graphics, you could probably put Vincent to good use.

I think getting Vincent up and running on the GP2X may be my first project.

​

I've been looking into making a port of an OpenGL ES lib as my first project as well. Perhaps if we collaborate, we can churn out a port pretty quickly. Send me an email or a PM, I'd love to help.

 

[K0K0NUT_h3lmut]

Woah, go for it guys! ^_^

 

[MiniMoose]

vincent is a good option. But it is designed for OPENGL ES hardware.

​

If you read the docs, Vincent supports fixed-point non-hardware accelerated platforms. It was originally designed for ARM powered PocketPC platforms without 3D hardware. That plus the fact that it is trying to be standards compliant is why I'm focussing on it over Klimt.

Vincent would be much easier to teach OpenGL ES programming with because of it's standards compliance.

 

[reallynotnick]

This looks awsome and if this means more 3d games on my gp2x then go for it! I would love to see it ported.

 

[Flexinoodle]

It's actually very very surprising how fast my Pocket PC runs 3D titles, Looking forward to see what you guys come up with.

 

[Ferentix]

Yes, this would be rather cool!

Any screenies of Vincent based games in action... hmm... *googles*

 

[MiniMoose]

Yes, this would be rather cool!

Any screenies of Vincent based games in action... hmm... *googles*

​

I don't have my 2X yet. It should be at my house sometime next week. My first priority will be to get Vincent rendering to an SDL window so that we can look at porting some SDL based 3D games.

The next step for me is to write my own frambuffer driver and get vincent rendering to it so that I can write games directly on the hardware, without Linux, in what Squidge describes as HH (hardcore homebrew? hardware humping? happy hoedown?) mode.

RobB already came up with a slick way to kill Linux and drop directly to the hardware so we'll be able to avoid flashing the unit to circumvent the penguin. You'll just launch the game and behind the scenes it will kill the kernel and take over the device. When you quit the game it will just reboot your unit back into Linux and your usual menu.

 

[slygamer]

I got the Vincent source code and have the libraries compiling under Windows. Yet to get the test application running though. After that, it shouldn't be too difficult to get something going on the GP2X (once I receive it).

 

[Hanz™]

How is this going?

GL2X and TinySDGL (I think this is a really really cut down opengl implementation).

 

[slygamer]

I got Vincent running. It is horribly slow. The code is a horrible abuse of C++. I won't work on it any more.

I also got TinyGL (not TinySDGL. Why use SDL?) running. It is a lot cleaner, but it is not a complete OpenGL implementation. It is not OpenGL-ES compliant either. It has no fixed point support, so it is using everything in floating point. Besides the lack of fixed point support, TinyGL always upscales textures to 256x256, which is ridiculous for a handheld, and the lighting is a bit wacky.

 

[slygamer]

I found this source code repository which has a GP32 version of TinyGL which apparently uses fixed point math. I'll check it out tonight once I grab the source code.

 

[slygamer]

I got the pspdev TinyGL code compiling and running on the GP2X.

Compare this in floating point as a straight compile of the original TinyGL code at 10fps

to this compile of the fixed point version from pspdev.org at 11fps

Same compiler options. Same linker options. All the same problems as the original TinyGL code (odd lighting mainly) plus a whole load of polys that aren't drawing for some reason, and only 1fps faster.

 

[Tobriand]

Speaking from a non-coder point of view (i.e. just a suggestion, and probably impractical), perhaps this is the wrong way to go about getting OpenGL on the 2x? I mean, there are other 3D engines - most notably Yeti - that worked very well on the GP32; why not try to modify them until you get something that's approaching OpenGL compliance?

True, it'd be a hell of a lot more work, and the engines themselves - whether Yeti or Quake - would probably need substantial modification (let alone the requirement of a port to the 2x in the first place from the GP32 in Yeti's case), but the result might be faster than a direct OpenGL implementation, at least if those you've tried thus far have all turned ou fairly slow...

 

[slygamer]

If Yeti has any assembly in it, then I'm screwed because I do not know ARM assembly yet. I haven't taken a close look at Yeti yet.

The effort to place any kind of OpenGL API on top of the Quake engine would be huge, if feasible at all.

 

[slygamer]

Yeti seems to be written to make Quake-style games. It doesn't seem very flexible.

 

[Tobriand]

Pity, though I did kinda think it'd likely be that way. Either engine, I'm sure, would need a LOT of adaptation before you could get anything remotely resembling OpenGL of any description. In Yeti's case, even more so due to the seeming inability (at least for now) to have rooms on top of one another.

On the other hand, the thing was and is ridiculously fast on the GP32, and therefore was worth suggesting just in case it *was* a possible route - the result would, presumably, have a much greater chance of being fast (if not easy to create). But if it can't be done, it can't be done - as I say, just a suggestion

 

[slygamer]

I've been taking a look at the Yeti GPL code, and it may be possible to use some of it. It has poly renderers, but I do believe it can only render quads.

The inability to have rooms on top of each other is because it treats the world as a 2D grid. Each cell in the grid may have one roof, one floor and optional walls. Hence the blocky nature of the demo levels. It also has hard-coded constants and effects for lava, water and sky.

I'm still working on it. I'll get something workable... eventually.