Sega Saturn Development > Share your code

3D Map tool + FPS demo

<< < (2/5) > >>

Danny:
You have been making a really wonderful job, your effort and dedication are inspiring!
I really like your videos, they show your progress from scratch and the evolution you have been having since the beginning.
It makes me really glad to see all the little bits of stuff I have been making put to good use ;D which makes me want to help out even more!

XL2:
Your contribution is highly appreciated!
I will improve the FPS demo (and tool) to work with the mesh loading you wrote.
People will be able to turn it easily into other genres (3d person games, RPG, etc.).
Hopefully this will bring more people on board! ;)

About the FPS demo : There is a bug with the controls, and I have the same problem with Sonic Z-Treme : it seems to always go faster one direction. Now, it might be something I don't understand about the >>#  and <<# functions and negatives/positives, but it's quite anoying when you are trying to move in diagonal.
Anyone got an idea about that? Johannes suggested a weird overflow issue, but I really can't find it.
Any suggestions for modifications to avoid that?

Danny:
Humm, it seems you are using the logical shift operators (https://en.wikipedia.org/wiki/Logical_shift), they might not be doing what you need/want, have you tried to change the code to use the "+=" and "-=" assignment operators instead?

XL2:
Yes, I played quite a lot with both in Sonic Z-Treme, overall I had much better results with logical shifts (You just wouldn't believe it unless you saw it).
But after reading the link you sent me, you are right, for signed int the shift right is different for positive and negative values.
Funny thing is that I wrote a workaround in Sonic Z-Treme by  adding 512 (Instead of using floats, I used integers where 1=1024 to keep precision at low cost, but shifted right when sending these for drawing and collisions, so >>10), but I thought I just wrote a cheap workaround.
I guess that might be correct as it will get rounded down after being shifted (-1+1)>>1=0, or (-1024+512)>>10=0.
I guess that also explains why SGL demos are almost always using Unsigned integers and are always doing shifts.

One small question : just how much does shifting saves/costs in Cpu cycles? And SGL demos doing shifts for just about everything, doesn't that waste some CPU ressources?

Danny:
In the early days logical shifts would be usually faster because the compilers were not very good at optimizing and the outcome would be more CPU cycles than needed, on more recent compilers that is no longer the case, the one we are using is relatively recent and I think will optimize correctly.
The problem with logical shifts its that it makes the code harder to read, at least the SGL demos were in my opinion messy and hard to understand at some points because of this.
In the end, if the outcome of the operation is the same, for instance the result of (10 << 1) and (10*2)  is the same (20), the compiler should compile to a binary left shift in either case, the difference is that its easier to understand on the second example. Now if you really want to do a binary shift and you really know what the binary shift is doing (for example, you really want some binary digits truncated) you should comment that line unlike those guys at Sega did. The code will be cleaner for someone else that reads it and even for yourself if you haven't picked it up in a long time.
I hope this helps  :P.

Navigation

[0] Message Index

[#] Next page

[*] Previous page