GP2X Tinygl Ported To Gp2x

[andrew_j_w]

Now that sparked my interest Are you working with the second CPU?

​

Yes, I think modifying an existing implementation of OpenGL to use the second CPU will be very tricky. I have designed my version from the ground up to use the second CPU. I have a simple client library that the treats the second CPU as if it were a GPU and sends it messages to render the graphics.

It's going to be tricky to get working right, but I think the idea is sound...

Andrew

 

[Radek]

Now that sparked my interest Are you working with the second CPU?

​

Yes, I think modifying an existing implementation of OpenGL to use the second CPU will be very tricky. I have designed my version from the ground up to use the second CPU. I have a simple client library that the treats the second CPU as if it were a GPU and sends it messages to render the graphics.

It's going to be tricky to get working right, but I think the idea is sound...

Andrew

​

But what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

 

[Dzz]

what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

I'm working on Yet Another 3D Engine for my own amusement, and I'm planning on doing the transformation part of the "pipeline" on the secondary processor and then doing rasterization on the primary processor. It seemed like a reasonable approach, i guess we'll see how much it actually helps.

When you say "what about the memory access?", what specifically do you mean?

 

[Radek]

what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

I'm working on Yet Another 3D Engine for my own amusement, and I'm planning on doing the transformation part of the "pipeline" on the secondary processor and then doing rasterization on the primary processor. It seemed like a reasonable approach, i guess we'll see how much it actually helps.

When you say "what about the memory access?", what specifically do you mean?

​

I mean the effective load/store perfomance as available bandwith is finite. As the first cpu will fill the pixels so the second better not interrupt its access to memory. For the best perfomance loading a bulk into a cache would be ideal. I was experimenting with some routines (mostly 2d/colors blending/blitting) and get that doing random "ldr/str" is much slower than rendering by scanlines (via "ldm/stm") so intermediate results fit in the cache.

But it will depends what the rasterizer will be doing. For simple polygons filled with just color it'd important but for textured surfaces (as they will be mostly limited by available cpu cycles) far less.

 

[Dzz]

I mean the effective load/store perfomance as available bandwith is finite. As the first cpu will fill the pixels so the second better not interrupt its access to memory. For the best perfomance loading a bulk into a cache would be ideal.

That's a good point. Lots of potential areas for efficiency gains, this stuff is fun.

 

[andrew_j_w]

But what about the memory access? Perhaps it could be better to use the second cpu for really processing intensive tasks like transforms and do it in bulks (to maximize effect of cache).

​

I have currently designed it so the second cpu does pretty much everything: it transforms and projects the vertices and renders everything to the screen. I wanted to leave us much time as possible for the primary processor to handle AI/Physics/Sound etc.

Of course there are a whole range of ways to tweak the performance, but I'm concentrating on getting things running first! Currently I do stupid things like clipping at the pixel level rather than clipping whole triangles. It might be stupid but it reduces the amount of code that can go wrong, and that's what's important at the moment

Andrew

 

[God Ginrai]

Your GL2X, this is theoretically going to be compatible with games that use OpenGL?

 

[andrew_j_w]

Your GL2X, this is theoretically going to be compatible with games that use OpenGL?

​

That's the plan. I have glQuake compiling using my library, but not enough of the OpenGL spec is implemented for it to actually draw anything useful on the screen.

Andrew

 

[BradN]

What kind of speed do you anticipate getting with your library, for example, do you think it would be competitive with the quake software renderer?

 

[andrew_j_w]

What kind of speed do you anticipate getting with your library, for example, do you think it would be competitive with the quake software renderer?

​

I really have no idea, I'll just get it running and go from there. I would expect it to be fairly fast as the software renderer only runs on a single processor, so there is bound to be some speed up. Whether the speed up will be enough to counteract the fact I'm writing a general solution rather than a heavily optimised specialist renderer I'm not sure.

@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew

 

[Pryankster]

@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew

​

No problem, no offense taken -- I'm not just looking at TinyGL -- I've also compiled up Klimt, which looks promising (already has support for Fixed point, for example) and seems to run faster than TinyGL (though the jury's still out, and real-life has intruded on my play time with the 2X :-( )

I'd be very interested in taking a look at your library when it's in a usable state.

My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster

 

[icurafu]

@Pryankster: Sorry, I didn't mean to highjack your thread - porting something like TinyGL is definitely the way to go to get OpenGL running quickly.

Andrew

​

No problem, no offense taken -- I'm not just looking at TinyGL -- I've also compiled up Klimt, which looks promising (already has support for Fixed point, for example) and seems to run faster than TinyGL (though the jury's still out, and real-life has intruded on my play time with the 2X :-( )

I'd be very interested in taking a look at your library when it's in a usable state.

My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster

​

Is this going to be comerical/shareware/freeware. It sounds very interesting. I'd be in helping out maybe...

 

[slygamer]

My plan for using 3D is in a (mostly 2D) RPG -- The characters/NPC's/Monsters will be modeled in 3d but move on a 2d backdrop, and I want the "world map" to be textured onto a sphere; but most of the game will be 2D.

-- pryankster

​

Damn you! You've been reading my mind, because that is exactly what I was planning to do (for one of my projects anyway).

 

[Julius]

Drop me a PM if you need 3D models for that project

 

[hmw]

Quick question on this thread: What's the current status on porting Vincent to the GP2X? Anyone had any success? I am still waiting for my GP2X to arrive, so I haven't have had a chance to get my feet wet myself... But I have started to experiment with a new rasterizer core, which should give this library an edge over the alternatives in terms of performance...

- hm

PS: Yes, I am the original author of Vincent...

 

[luteijn]

Quick question on this thread: What's the current status on porting Vincent to the GP2X?
- hm
PS: Yes, I am the original author of Vincent...

​

see: [url="http://www.gp32x.de/board/in...2x.de/board/index.php?showt...09&#entry326609
[/url]

I think the part about slow and being a horrible abuse of C++ has scared off everyone else...

P.

 

[slygamer]

That was me who tried a port of Vincent and posted those comments. Trying to get Vincent to compile under GCC was an arduous task, compared to TinyGL that compiled almost straight off the bat. Then trying to follow the code path through Vincent was made extremely difficult by the over-use of C++ classes and templates. They do not make debugging any easier. Once I got Vincent running and spinning the Dodge on screen, the textures were screwed up, and given the complexity of the C++ code, I gave up trying to find the problem.

Sorry for the critical comments on your code, but that is my honest opinion.

 

[Julius]

But hey... all this shouldn't be a problem for the original creator

Geat to know he is onboard of the GP2X community also!

 

[slygamer]

If he can get it going at a decent rate, more power to him.

 

[hmw]

That was me who tried a port of Vincent and posted those comments. Trying to get Vincent to compile under GCC was an arduous task, compared to TinyGL that compiled almost straight off the bat. Then trying to follow the code path through Vincent was made extremely difficult by the over-use of C++ classes and templates. They do not make debugging any easier. Once I got Vincent running and spinning the Dodge on screen, the textures were screwed up, and given the complexity of the C++ code, I gave up trying to find the problem.

Well, I'll see what I get. But I am a bit surprised about your difficulties getting it compiled on GCC, because the Symbian builds use GCC, and patches of several others for various versins on Linux have suposedly been merged into the code base quite some time ago (after 0.80). But gcc also changed a lot between 2.9.x and 4.x. For the srewed up pictures, that was using the JIT, I guess? That's the part people usually have problems with when going to a new platform.

To my knowledge Vincent uses templates only for the texture format conversion in the inner loops of the image copying code to load textures, as well as for small array-of-<T> classes. It sounds that you were trying to debug the texture loading code then. Do we need to add support for different formats beyond the ones that are provided?

- HM