GP2X Vincent For Gp2x Alpha

[hmw]

OK, so I am posting a first build of the Vincent library for the GP2X. You can download it here.

This time, I am including both the source as well as binaries. It's not a full distribution yet, hence I am posting it on my personal web page instead of Sourceforge (even though all the code is checked in, too).

The little demo program is in bin/gp2x/release. Copy test.gpe and the image file dodge.raw out of the test folder onto your SD card in order to try the example.

The new rasterizer improved things, but not as much as I had hoped. The demo car (732 triangles) spins at 17-20 fps, depending on the view. (mipmap nearest, nearest texel, depth buffer, culling). For performance freaks, you can find specialized versions of the inner loops in RasterizerPieces.cpp that you can hook up in RasterizerTriangles.cpp (look for the comments, it's obvious). While usually these inner loops are compiled at runtime using the built-in JIT, you might want to experiment with these versions to see how far you can stretch performance. In the form supplied, the difference makes up 1 fps (e.g. 18-21 fps).

I haven't tested everything yet, so it's quite likely that you will run into glitches here and there. If you do, let me know.

So what's left to do besides bug fixing?

• Rework the transformation path from eye coordinates to clip coordinates and clipping for better precision. This distribution has for speed reasons the code from build 0.84, which won't pass the conformance test.
• Adapt the surface class to SDL
• Implement the scissor test in the triangle rasterizer.
• Investigate addition of specific hand-optimized inner loops into the rasterizer
• Optimize the coordinate selection and geometry/lighting code
• Lazy lighting: move lighting calculations after culling
• Improve global register allocation in JIT
• Start experimenting with dual-cpu support

Well, have fun...

- HM

 

[Dingo_aus]

Excellent news - very very exciting stuff, thanks

 

[PokeParadox]

Well this sounds great, I think I'm going to have a little look at that source

Thanks, great stuff.

 

[gdelappa]

[Update] Nevermind

Where is the download? Thanks

 

[Imerion]

Now this is really cool! It certainly has much potential. Hope people will use it once its done.

 

[hmw]

Now this is really cool! It certainly has much potential. Hope people will use it once its done.

​

Just as an update: As I am running my regressions, I realize that some very fundamental stuff is broken in the current build out there. I'll post an update later tonight...

- HM

 

[hmw]

I updated the build on the download page http://homepage.mac.com/hmwill/FileSharing6.html.
There is still one crash I get when using texture combine (GL_COMBINE) with certain parameter settings that I need to track down. I also had to partially back out some of the changes I had made to the register allocator, because later stages cannot handle those cases yet.

Once those items are addressed, I would consider this code stable enough to go through the regular sourceforge distribution.

- HM

 

[Dingo_aus]

Here is a binary that is 99.999999% the same as the HMW's original demo but allows you to use the joystick to control the rotation and the volume buttons to control the zoom in and out.

You obviously still need both the binary and the raw texture.

http://www.users.on.net/~symes/other/test.gpe
http://www.users.on.net/~symes/other/dodge.raw

 

[hmw]

Here is a binary that is 99.999999% the same as the HMW's original demo but allows you to use the joystick to control the rotation and the volume buttons to control the zoom in and out.

You obviously still need both the binary and the raw texture.

http://www.users.on.net/~symes/other/test.gpe
http://www.users.on.net/~symes/other/dodge.raw

​

Thanks for providing this. Reminds me that I should chop-chop with my outstanding fixes . I have 5 more regressions to go... At the same time, if anyone is interesting in chipping in, let me know.

- HM

 

[PokeParadox]

I don't think I can help with the lib, but I will say I am liking this. When I actually have some time I'm going to have a play around with it and put a simple program together.

What's currently putting me off is the fact that the only oGL I know currently involves Glut... which this doesn't have. So I basically have to read up on how to do things without having to use Glut.

Keep up the good work

 

[Dingo_aus]

I'm happy to help as much as I can - are there things other than this list?:

* Rework the transformation path from eye coordinates to clip coordinates and clipping for better precision. This distribution has for speed reasons the code from build 0.84, which won't pass the conformance test.
* Adapt the surface class to SDL
* Implement the scissor test in the triangle rasterizer.
* Investigate addition of specific hand-optimized inner loops into the rasterizer
* Optimize the coordinate selection and geometry/lighting code
* Lazy lighting: move lighting calculations after culling
* Improve global register allocation in JIT
* Start experimenting with dual-cpu support

I'm part way through a very basic and unoptimized file loader (so i can load cubes and teapots as opposed to Dodge Vipers ) and am also about to start a Blender export script for the same format.

If there is anything more part of the OGL implementation itself you want me to look at please advise where you think my efforts would be most useful. (ie what you haven't already done etc)

 

[hmw]

I'm happy to help as much as I can - are there things other than this list?:

I'm part way through a very basic and unoptimized file loader (so i can load cubes and teapots as opposed to Dodge Vipers ) and am also about to start a Blender export script for the same format.

If there is anything more part of the OGL implementation itself you want me to look at please advise where you think my efforts would be most useful. (ie what you haven't already done etc)

​

What kind of file format are you using? And did my previous post concerning the data structures make any sense to you?

I got the crashes resolved last night ; the remaining bugs should be fairly simple to fix. So the next build I am going to post later this week will have:
* Reworked transformation path from eye coordinates to clip coordinates and clipping (better precision & speed)
* More efficient coordinate selection and geometry/lighting code
* Lazy lighting: lighting calculations after culling
* Some change to register allocation; there is a bigger improvement still outstanding, but it will require a little more work

I might ask for some guidance about SDL support. Also, just looking into the code for apparent bottlenecks or performance gains would be a good thing. Finally, I might ask for some guidance concerning speed vs. quality tradeoffs.

- HM

 

[Julius]

Finally, I might ask for some guidance concerning speed vs. quality tradeoffs.

​

Go for speed in every case

Sorry can't really help, but thanks alot for your work so far!

 

[PokeParadox]

Yeah I don't think on a platform like the GP2X anything other than speed is worth consideration.

 

[hmw]

Yeah I don't think on a platform like the GP2X anything other than speed is worth consideration.

​

Yeah, right... until it's YOUR code that produces over/underflows in fixed point that you haven't seen on the desktop version you have been porting over...

- HM

 

[slygamer]

I see that you are planning to change the Surface class to use SDL. Will it remain an option to not use SDL?

 

[hmw]

I see that you are planning to change the Surface class to use SDL. Will it remain an option to not use SDL?

​

Well, as you have seen, the whole interface to rendering surfaces is wrapped into the EGL layer and the surface class (egl.cpp, Surface.cpp). My personal first choice is still Paeryn's hardware accelerated SDL because

• SDL as a whole is a more complete and documented platform for porting games compared to the minimal library.
• It might also be easier to debug, because much of the work can be done on the desktop development machine.
• It's probably easier to combine 2D and 3D content onto a single screen because you have a common surface abstraction

That said, I won't exclude direct surfaces, and for dual core support the minimal library still seems to be the only choice available (but that would be internal to Vincent compared to the public interface). Unless there is now a more 'official' way.

What's you main concern aginst SDL? The library footprint?


- HM

 

[slygamer]

I have never used SDL, and I do not intend to use SDL. My code runs as close to the hardware as it can. If there is an option to allow us to specify our own framebuffers, then all would be good, otherwise I guess I could rewrite the Surface class to suit my own code.

 

[hmw]

Well, yes, you'll still be able to use direct access.

- HM

 

[synkro]

converting to SDL surface seems to be the right way.