Jump to content


Photo

Vincent For Gp2x Alpha


  • Please log in to reply
24 replies to this topic

#1 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 19 March 2006 - 06:14 AM

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

#2 Dingo_aus

Dingo_aus

    GP32 Hardcore

  • Member
  • PipPipPipPip
  • 124 posts
  • Location:Brisbane, Australia

Posted 19 March 2006 - 10:36 AM

Excellent news - very very exciting stuff, thanks

#3 PokeParadox

PokeParadox

    Founder of Pirate Games - Penjin Coder

  • GP32 Hardcore
  • PipPipPipPipPipPip
  • 3908 posts
  • Gender:Male
  • Location:UK
  • Interests:Homebrew and Emulation!

Posted 19 March 2006 - 12:30 PM

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

Thanks, great stuff.

#4 gdelappa

gdelappa

    GP32 User

  • Member
  • PipPipPip
  • 53 posts
  • Location:5501 glenridge drive apt 706 30342 Atlanta, GA

Posted 20 March 2006 - 12:40 PM

[Update] Nevermind

Where is the download? Thanks

Edited by gdelappa, 20 March 2006 - 12:41 PM.


#5 Imerion

Imerion

    GP32 Hardcore

  • GP32 Hardcore
  • PipPipPipPip
  • 218 posts

Posted 20 March 2006 - 09:05 PM

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

#6 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 21 March 2006 - 01:49 AM

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

View Post

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

#7 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 21 March 2006 - 07:58 AM

I updated the build on the download page http://homepage.mac....leSharing6.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

#8 Dingo_aus

Dingo_aus

    GP32 Hardcore

  • Member
  • PipPipPipPip
  • 124 posts
  • Location:Brisbane, Australia

Posted 01 April 2006 - 09:39 AM

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..../other/test.gpe
http://www.users.on....other/dodge.raw

#9 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 02 April 2006 - 09:51 AM

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..../other/test.gpe
http://www.users.on....other/dodge.raw

View Post

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

#10 PokeParadox

PokeParadox

    Founder of Pirate Games - Penjin Coder

  • GP32 Hardcore
  • PipPipPipPipPipPip
  • 3908 posts
  • Gender:Male
  • Location:UK
  • Interests:Homebrew and Emulation!

Posted 02 April 2006 - 11:17 AM

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 :)

#11 Dingo_aus

Dingo_aus

    GP32 Hardcore

  • Member
  • PipPipPipPip
  • 124 posts
  • Location:Brisbane, Australia

Posted 02 April 2006 - 09:29 PM

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)

#12 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 03 April 2006 - 05:03 PM

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)

View Post

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

#13 Julius

Julius

    Mega GP Mania

  • GP32 Hardcore
  • PipPipPipPipPipPip
  • 848 posts
  • Location:Germany

Posted 03 April 2006 - 06:12 PM

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

View Post


Go for speed in every case :P

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

#14 PokeParadox

PokeParadox

    Founder of Pirate Games - Penjin Coder

  • GP32 Hardcore
  • PipPipPipPipPipPip
  • 3908 posts
  • Gender:Male
  • Location:UK
  • Interests:Homebrew and Emulation!

Posted 03 April 2006 - 06:58 PM

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

#15 hmw

hmw

    GP32 User

  • Member
  • PipPipPip
  • 42 posts

Posted 03 April 2006 - 08:33 PM

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

View Post

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