[Wip] Dungeon Crawler OS4 (a friend project)

Found this an aw.net Really nice project. I just linked to the youtube clip. Was some stills, but didn't bother with those.
Let's hope he can make this into a finished project.Looks promising.

Quote:

fantastic look forward to the end product.

Looks really nice.

Am I imagining it, or has there been more app/game developer activity lately? When reading through the last AmigaFuture magazine, it seemed like there were more new software releases than normal, particularly games. Over the last few weeks a number of small games have also been released. And, now this WIP project appears...

I have to say that I'm impressed with this project. The performance looks good on modest hardware, and he's even experimenting with normal mapping without having access to shaders. I had a snoop around the French Amiga forums, and discovered that he's gone "old school" and is using Warp3D directly instead of using MiniGL. No doubt this will get better performance out of Warp3D.

The one concern that I have is that it sounds like he's doing the whole project alone; software development, graphics, sound, the lot. If that's what he wants to do, then that's fine. However, creating a game like this is a big project. It would be much better if he had a small team that understand his vision for the game helping him out. I'm sure that there are people here who could help.

All the best with this project Crisot.

Hans

@Hans
I feel the same. Its a very positive feeling right now

Looks impressive, congrats.

I think with os4.2 we will have more ported games as it will probably be easier to do porting as the new gfx system and ofcourse Radeon HD drivers. I hope we get more demos too.

@Hans

True indeed, Crisot wants to do everything alone. It's a kind of challenge for this "lonely developper" ( ;) ). And seeing the past, too few teams have managed to achieve their goals (someone leaving the team, another one disagrees with the path selected, etc...).

Fortunately, Alain Thellier (Wazp3D developper) is helping him with his knownledge of Warp3D and AmiDark, Alexandre balabaln and other French developpers car bring some help too whenever Crisot needs some.

And eventually French Amigans give their opinion whenever Crisot asks for it.

BTW Crisot hates MiniGL in its actual form and cand realize really nices things (remember this demo : http://os4depot.net/index.php?functio ... se/universe-two_kitch.lha ? All done with Warp3D thanks to an engine created by Crisot himself ).

@K-L

Quote:

Okay. I can understand that. A bad team that doesn't understand or agree with the team leader's vision can indeed be a big problem. However, a good team makes success much easier and faster. Anyway, it's his project.

Quote:

I know. I read some of his MiniGL criticism, and I disagree with a lot of what he says. I have refrained from commenting so far, but since you brought it up...

Crisot is absolutely correct that using Warp3D directly will give you better performance than using MiniGL. His preference to use Warp3D directly isn't surprising given that he knows how to use it and is writing stuff from scratch. However, his criticism of MiniGL is overly harsh because there is no way that any OpenGL via Warp3D library could be made without adding performance reducing overhead.

Crisot claims that MiniGL renders polygons one by one, but that's not true. It assembles them into vertex arrays even when the app/game developer provides vertices one by one. So, it renders groups of primitives at a time (where possible). Developers should be passing MiniGL vertex arrays, anyway. In fact, MiniGL even supports the GL_EXT_compiled_vertex_array extension, which Quake 3 uses to improve performance. I tried disabling this extension once, and the difference was noticeable. Sadly, very few know that this extension even exists in the OpenGL specification.

Crisot complains about MiniGL's locking method, which is unusual. However, it's unusual for a reason. MiniGL holds on to the lock as long as it does is to maximise performance while minimising audio stuttering. Yes, you read correctly: the smartlock mode maximises performance while minimising audio stuttering. The difficulty is that OpenGL has no concept of hardware locking, and so doesn't indicate when is a good time to lock and unlock the hardware. Hence, the complicated locking system. It is possible to set MiniGL to manual lock mode and take full control, but most people aren't going to do that, especially with *nix ports. Even then, a custom Warp3D engine will be faster...

MiniGL is significantly faster than StormMESA. I don't know the exact numbers but, IIRC, it is at least twice as fast. The bottom line is, mapping the OpenGL API to Warp3D efficiently isn't easy, and MiniGL does a pretty good job. There may well be a more efficient method, but it will never be anywhere near as efficient as using Warp3D directly.


Let's not get sidetracked by arguments over APIs and libraries.
I think that it's great that Crisot is developing something specifically for AmigaOS. It's also great that he's working on it right now with what's available instead of waiting for AmigaOS 4.2. I honestly couldn't care less if he uses MiniGL or Warp3D, C, C++ or E, or anything else for that matter. The results look promising, and that's what matters.

Hans

I have never stopped enjoying a game when I realised it wasn't written in language x y or z ;)

@Hans

I was not criticizing MiniGL (since I do not know anythingabout it : I'm a simple user).

I just said that Crisot hates MiniGL in its actual form to explain why he was using Warp3D.

He posted, indeed, on Amiga-NG.org why but he did not want to create sterile debate about this.

Crisot comes from the Classic world, he was one of the 1st to create Warp3D demos with the Universe group of demo makers. He created really fast engines with Warp3D.

Anyway, the real good news is that he is working on a project. Whatever is used to acheive it, the simple user really doesn't care about it

PS: I'll tell him to check out what your wrote by the way

Quote:
I was going to say, don't bother, but I see that you already have. And, he's continuing to insist that he's right. I could provide counter-arguments, but there really is no point in wasting more time on this. He prefers using Warp3D directly for obvious reasons (he knows how to use it properly), and MiniGL is pretty good at what it does (regardless of how harshly he criticises it).**

Having said that, I invite him to switch MiniGL's lock mode from "smartlock" to "automatic." Automatic mode locks Warp3D only during rendering. I invite him to watch MiniGL slow to an absolute crawl. Absolutely no audio stuttering though...

Hans


** To anybody who doesn't believe me on this point, I challenge you to develop a faster OpenGL via Warp3D implementation. You might even succeed, but how long will it take? Actually, no, please don't bother; I'd rather that you spent your time doing something useful.

Hans,

I've looked using google for your GL_EXT_compiled_vertex_array extension
and I've seen that it is used this way :
Quote:
Is it correct ?
I've effectively seen in the glext.h file that these 2 functions : glLockArraysEXT & glUnlockArraysEXT are available.

I will test them with the AmiDARK Engine to see if it improves performances :p

If you have any other tips to increase MiniGL performances, plz ask them :p

Regards,
AmiDARK

@freddix

I don't have a good example for GL_EXT_compiled_vertex_array, but your code snippet is basically it.

It's only applicable when the same vertex array is used multiple times in a row. For example, the same vertex array might be rendered in multiple passes with different textures and texture settings.

MiniGL takes advantage of this extension by not recalculating transformations, etc., while a vertex array is locked. The MiniGL docs says that this is "experimental," but it can do everything that Quake 3 needs it to.

My only other tips for increasing performance are ones that you probably already know:
- Use vertex arrays. Do NOT use glBegin()/glEnd(), etc.
- Smooth shading is actually faster than flat shading with MiniGL (IIRC, flat shading is better emulated by rendering triangles in smooth mode with the same normal for each vertex rather than using smooth shading)
- Rendering triangles/tri-strips/tri-fans is faster than rendering larger polygons
- Rendering many polygons in a few vertex arrays is faster than a few polygons in many vertex arrays (true in Warp3D too, and Crisot will back me up on this )
- Try to order rendering from close to far away to minimise overdraw (no point in rendering pixels that get overdrawn later)
- If possible, rendering vertex arrays using the same texture in a row is better than switching textures all the time (reduces texture cache flushing)**
- Anything that copies data to textures is slow (Warp3D stores a copy of all textures in main RAM)
- Get a faster graphics card

Finally, there are the techniques that make the difference between a "tech demo" engine and a highly scalable graphics engine that can render huge world:
- Use visibility culling techniques (e.g., bounding volumes) to avoid rendering vertex arrays that are definitely not visible
- Render far away objects with fewer polygons (i.e., use Level Of Detail (LOD) control techniques)

Hans


** The effect of this optimisation is probably pretty small compared to the overhead of software TCL

Hans,
Thank you for your advices.
I already know some of them (LOD, Culling) even if I don't yet use them (the 3D engine is in early alpha preliminary state :p) but some of them will probably be helpful when I'll really start the 3D engine development.

in the AmiDARK Engine, we can create "instances" of 3D Objects. That mean that there is 1 single 3D object with the mesh and textures data and you can create copies of it you place everywhere in the 3D world.
But, these copies will be at different positions/rotation than the original object. However, they will use the "source object" mesh and texture for render.
Does the GL_EXT_compiled_vertex_array may be interesting in that case ?

Later, I'll add new commands in the 3D Engine to do what we can call a "static world". It will consist in 1 objects that will contain all objects that NEVER MOVE in the 3D world (environment). Probably the GL_EXT_compiled_vertex_array can be applied to these *special* objets ;)

Quote:

Because Warp3D doesn't support hardware Transformation Clipping and Lighting (TCL), if you change the position and orienatation, then the TCL calculations must be redone. Hence, the cached vertex arrays would be useless. So, it can't be used to speed up rendering the same vertex array in multiple locations.

AFAIK, it's main (only?) advantage is for multi-pass rendering effects. Looking at how Quake 3 uses it would give you the best idea as to what it's good for.

EDIT: I forgot to add that it doesn't matter if an object is static or not. Only one vertex array can be locked at a time, so it only speeds things up when the same array is used multiple times in a row.

Hans

Ok Hans,

In that case, the interest is that the "static object" can also be called "static world" a bit like BSP were.
So, as it is a large object that will contain the (static part of the ) entire map of the game, it may be interesting to lock it... I keep this idea in my "to do list" for the Static Objects.

Thank you for all advices.

Regards,
AmiDARK