AGS 3D

[Kweepa]

I removed invert mouse from the hotkeys.
If you want it you have to call

Code: ags

Ags3d.SetMouseLookInvert(true);

in, for example, game_start.

Oh yes, you can walk through Scids just as you leave it. I'll have to fix that.
Of course you won't be able to walk back behind the buildings. But the slowdown when looking at the wall in the alley (along the row of buildings) needs to be addressed.

[EDIT] Slight speedup with v1.09, which allows primitives to be parented to other primitives for rendering/sorting purposes. In the demo, the doors and signs are all parented to the buildings.

[EDIT] Also, pressing F7 toggles draw sorting so you (ok, I) can see how much sorting affects the performance.

[Gilbert]

About performance issues, I think it's pushing the engine quite hard at the moment (mainly due to the complexity of the town square now).
Even with a 2.5GHz here the frame rates can drop to below 20 at times.

And I'll say one of the case where an extreme is hit is like:

Firstly, the priority is obviously incorrect. Secondly, it's pushing the engine too hard that at times the game can freeze for nearly 2 or 3 seconds when you move at some angles in the abouve position (remember the testing comp. is a 2.5GHz), I think when you want to invest on the sorting a bit more, you may check what's actually happening when you're standing there, probably helps to do some more optimizations and maybe kick away some reduncencies.

[Kweepa]

The sorting is wrong there because I deliberately draw the graveyard wall before any of the other buildings, as an optimisation. In a game, the player will never get to that position.
Can you check the compiled folder for a log file or a txt file? Because the game shouldn't ever freeze for 2 seconds.
There's very little I can now do to speed up the sorting I'm afraid, aside from putting it all in a plugin. You could try dropping the resolution to the recommended 320x240... that should gain you back a few FPS. What framerate do you get when you switch the sorting off (F7)?
If I could decouple update and render it wouldn't matter so much that the framerate dropped to 15 or 20. That's why I started that thread about accurate timing. Doesn't look like I'll be able to do that.

[Gilbert]

Can you check the compiled folder for a log file or a txt file? Because the game shouldn't ever freeze for 2 seconds.

Nope, there're no warning.

You could try dropping the resolution to the recommended 320x240... that should gain you back a few FPS. What framerate do you get when you switch the sorting off (F7)?

It's a bit less choppy running at low-res, disabling sorting gives a little bit of speedup, but it doesn't help much (the compiled game disabled the editor, so me lazy gut had to recompile it to re-enable it ). The major freezes appeared only at hi-res, at low res it's not that noticiable, but it's still choppy at that position.


Also, I think in the module code, when you defined the version constant 107 was defined twice, shouldn't one be 108 and maybe you can add 109?


P.S. I have a suggestion, but I don't know how feasible it is: is to provide primitives of single flat faces apart from the current 3D objects. You may make these flat faces primitives linking to faces of the created 3D objects.
This can help, for example in making the doors, the "water" of the pool and the windows, etc.
IMO, doing this has several advantages:
1. They can now be "flat" on the surface of teh objects instead of the currently beveled blocks (like the doors, etc.) which look better.
2. You only need to draw that face on top of the base object's face (if that base object face is visible, for example, if the wall with a door is visible draw the door on it), no need to do other complicated calculations (including orientations, sortings, etc.) for those extra faces.

[Rui 'Trovatore' Pires]

Little tip - I'm sure you'd get better results for the "Scid's" and "Yahtzeebrand" signs if you used a single sprite with all the letters instead of the solitary letters. 1 - there're less sprites, and 2 - currently each letter has it's own "rotation", so to speak, which lends itself to very weird effects.

[Kweepa]

Little tip - I'm sure you'd get better results for the "Scid's" and "Yahtzeebrand" signs if you used a single sprite with all the letters instead of the solitary letters. 1 - there're less sprites, and 2 - currently each letter has it's own "rotation", so to speak, which lends itself to very weird effects.

No, if I use a single sprite for the sign, it would be even worse - the base and top have to be horizontal on the screen, so if the area the sign is placed on is off-level due to the viewing angle, it would look ridiculous.

[Kweepa]

Well, I cracked and wrote a plugin:
http://www.steporg.com/step/ags/games/ags3dp.zip
It doesn't draw sprites yet as I haven't worked out how to scale (or scale and rotate) them.
Nor does the text rendering seem to work, unfortunately (I think I'm calling the function wrong).
And keypresses are off too - AGSE_KEYPRESS doesn't send the keycode in 'data'?
Still, it's a little faster than the module...

[Rui 'Trovatore' Pires]

A little? The framerate is steady at 39-40, and sometimes 41.

If the plugin gives you trouble in some areas... well, I for one wouldn't mind having to use both a plugin AND a script module to get the thing done.

[Gilbert]

Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

It's mostly related to the dynamic sprite operations. WhenÃ,  you're close to a sprite, since it's scaled to a large size (and in worse case it's banked, so it has to be rotated and there'll be intensive calculations and memory usage. When the game is in 640x480, a scaled sprite even takes up about 4 times of memory compared to 320x240, and I just noticed that when these pauses happened the HDD was being accessed, so it's probably suffering in a "low" memory system (256 MB here, but I was running some memory eaters in teh background).
One regeneratable problem (in my computer) is near that screenshot I previously took , walk near the wall and look up, there'll be a tree sprite scaled and rotated which is nearly the size of the screen.

I'm almost certain about this, since I tested it by commenting the content of DrawSprite() (which is the only place dynamic sprites are used), the FPS rised drastically.

So, I had tried several tests:
1. Increased sprite cache to 20MB (previously tested with 10MB) in setup, seems to help a little bit, but not much.
2. Rearranged some of the lines in DrawSprite(), since a sprite is to be drawn only based on a small amount of factors (actually based on values of iw and ih), I made it so lots of floating-point calculations and dynamic sprite operations won't be executed if the sprite is not going to be drawn anyway. It seems to give me some significance boost in speed.
3. Seems that on the long run, dynamically declaring local variables and destroying them repeatedly does eat CPU power (especially when it's a pointer variable, which is repeatedly allocated memory to and destroyed many times in a game loop), which are quite frequent in a complex "game" like AGS3D. So, I tried to do the dirty job of putting the declaration of the pointer ds outside of the DrawSprite() function, and the result was quite impressive here (still a bit choppy in critical cases, but much better than declaring it inside of the function).

Here is a dirty hack I tried on it, it includes point 2 and point 3 above, you may take a look around the DrawSprite() function on what was actually (messily) changed. Apart from that, I also tried to do some small optimizations (like simplifying some expressions, and like moving int j; outside when you're doing stuff like while (i...){ while (j...), etc.) but I think they won't lead to much noticiable difference and they're making teh codes even harder to read, so just ignore them.

Edit: Oops there's something I forgot to comment, so some uncessary operations were don tice, should be fixed now.

[Rui 'Trovatore' Pires]

Whoopsie again. And in this case changing room is not a good option...



I say, these thingies CAN be corrected, yes? By the coder, I mean. We don't HAVE to insert room changes because of these issues, is what I mean to ask.

[Kweepa]

Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

Wow, thanks for the research!
It doesn't make any noticeable difference on my machine - so I'll use your changes if it helps for low memory cases (I've got 512Mb). If you put a Display() command inside the "if (bank != 0)" test I had you'll see none of the sprites in room1 are banked, so dynamic sprites are never used. I'm surprised that just creating a pointer to a dynamic sprite is so slow.

Yeowch, I've noticed that occasionally the game can allocate 70Mb when the sprite is drawn scaled up! Turning off the sprite compression doesn't seem to make any difference.
That's nasty. I'll have to limit the sprite size.

Rui, I see that happens without changing rooms too. So I'm not quite sure what the question means.

[Rui 'Trovatore' Pires]

Let's suppose you wanted to elliminate the sorting problems which have come up (one of which, the first, is not an accident; the second of which, I believe, is). The first solution, the one you suggest, is to change rooms before that problem can even take place. I was wondering if there was a SECOND solution - i.e., if it was possible to thoroughly eliminate such sorting problems.

[Kweepa]

Aah, I see what you mean.
I haven't investigated the cause of that second (unwanted) sorting problem.
So I can't say for sure whether it's just a bug, or whether it's inevitable given my sorting algorithm. Painter's algorithm can have circular dependencies which have to be arbitrarily broken.
Cheers!

[Gilbert]

Hey, I think I'm almost certain of the causes of the pauses under hi-res I mentioned earlier.

Wow, thanks for the research!
It doesn't make any noticeable difference on my machine - so I'll use your changes if it helps for low memory cases (I've got 512Mb). If you put a Display() command inside the "if (bank != 0)" test I had you'll see none of the sprites in room1 are banked, so dynamic sprites are never used. I'm surprised that just creating a pointer to a dynamic sprite is so slow.

Yeowch, I've noticed that occasionally the game can allocate 70Mb when the sprite is drawn scaled up! Turning off the sprite compression doesn't seem to make any difference.
That's nasty. I'll have to limit the sprite size.

Yeah, I'd noticed it too, the critical line is the RawDrawScaled() line, there're times where a sprite can be scaled even larger than a screen (especially when you're close to a "tree"), for scaling a sprite to say, 320x240, is actually scaling it to 640x480 in hi-res, so it's very intensive, commenting the rawdraw line speeds up a lot, so that's the offending line. Maybe people who use this shall design their scenes so the sprites won't get too large (like putting walls in front of the trees to prevent you from getting too close, etc.).

[Kweepa]

Well, just in case, I've limited sprite scaling to 640x480. I should probably make it a function of the original size but for now that'll probably do.
I also moved the DynamicSprite pointer outside the function.
And I fixed a couple of sorting bugs found by debugging the plugin (hurrah for debugging!) - including the one you got a screenshot of, Rui.
Version 1.10

[Rui 'Trovatore' Pires]

Over 'ere it's still slow, but it's not chppy any longer.

[Kweepa]

I think at this point the module is ready for release...
Gilbot, your suggestion of flat polygonal primitives attached to the faces of other primitives is interesting, but it would require a significant rework of the engine and I don't have the motivation to do it. I don't think it would massively improve the framerate - much of the slowdown (in the town square) is due to
(a) sorting the main objects (the buildings)
(b) overdraw

I'm not quite sure what to do about HoN's texture mapping additions. To use the texture mapping you need to switch off the free look up and down, and importing a texture is a painful process (cutting it up, making sure it's sequential sprites). The backdrop is an interesting addition but can mostly be replicated with draw first primitives and sprites placed out at the horizon, as shown in the latest version of the Reality Town Square.

I also increased the primitive limit to 100 (from 60), mostly to accommodate the 20 clouds.

Version 1.11 is here:
http://www.steporg.com/step/ags/games/ags3d.zip

[Rui 'Trovatore' Pires]

Ready for release? Ok. I'll wait for a couple more days, then up it to my site.

And - jolly great wonderful piece of work there.

EDIT - Funny thing, but PgDown as "move down" no longer works. Sure, I can get around to it by pressing F6 to start falling and pressing it again to stop, but I thought you might like to know.

[DoorKnobHandle]

Amazing work, Steve. At this point I am going to thank you, Steve (and everyone else that contributed to this) for spending your time on this project. I am really happy it turned out this way - I was afraid after releasing the original AGS3D source code for that "Release Something" event several months back that simply noone would contribute to this...

*emo mode off*

[Kweepa]

EDIT - Funny thing, but PgDown as "move down" no longer works. Sure, I can get around to it by pressing F6 to start falling and pressing it again to stop, but I thought you might like to know.

Oops. Lost a minus sign somehow.
It's working again.
Version 1.12.

Should I move this to a new topic to "announce" it, or just leave it here?