Snes Mode 7 followup

[Mike Halliday]

@~J~

Have you got anywhere with the Mode 7 style display you were looking at?

Its been a while since you offered to have a look, and to be honest, I have been lazy and not looked at it since! Sorry.

Anything you have to share would be great. I might even have another go at it soon.

Cheers

Mike.

(I tried to PM you, but you are set to not receive PMs!)

[kornalius]

I'd like to know too because that would be an amazing feature for the GameAPI.

[Mike Halliday]

Well, I have been looking at the Mode 7 thing again, basically because there has been no progress on it at all.

So far I have the track map (top left) and the enlarged map (bottom 1/2 of screen)

Working out how to project the pseudo 3d effect.

Currently the top map moves and rotates, and the bottom display changes accordingly when using the arrow keys.

Will keep you all posted on future progress;

Mike.

[Mike Halliday]

Still struggling to get the perspective right;

Here is my code, if some one wants to have a go?

The code should produce the 'ProperMode7.jpg' result (this is what I am after)

Currently the attached code only displays a magnified version of the smaller map! :(

Ta.

Mike.

(Also attached is the document on Mode7 mapping theory that I am trying to follow - but not having much success!)

[Nicknack]

I have also made a small code to try it out, it might a bit more perspective correct than yours but it's even slower :D
here is a screen:

[Mike Halliday]

Much better perspective than mine! :)

Can you post your perspective code? Maybe we can work on this together and get a Mode7 display for PPL?

M.

[Nicknack]

ok here it is ;)
my idea was to have this view rectangle which covers the area of ground you can see. it lies always parallel in front of you and is rotated with you. take a look at this screenshot, the green point is your position and the blue is this view rectangle.
now you find out the color of every pixel in this rectangle and draw with this information the view rectangle enhanced and rectified onto screen.
I have included one commented version (explanation.ppl) and one enchanced (color values are stored in array instead of surface) .
a further method to improve it might be a faster way of converting the rotated pixel values of the view rectangle back to screen coordinates.

hint: play around with the resolution get a better speed or picture

[c4esar]

Hi!
Don't want to bother, but I'm very interested in your project.
And I remembered my art teacher telling me (decades ago ;) ) that one should consider the "golden section" to achieve virtual depth in a picture.
I could imagine that this would be helpful for games, too.
That means the simulated horizon should be located at 92 px from below (or 92 px from the top, depends on the scene) if there are 240 px of height.

(the golden section is calculated by dividing one member of the Fibonacci sequence by the following member e.g. 8 / 13 or more precise 144 / 233 what leads to a value about 0,618 ..thanx to google :) )

[kornalius]

Ok, I have to say that I am in total shock to see what you guys are achieving with the GameAPI. Keep it up, it is very interesting to follow...

[zehlein]

You guys got me hooked and I thought I might have a go on this too. :D
This is my first attempt, moving forward, backward, left and right. No rotation yet. But at 20 fps :)

[Nicknack]

yay scanlines :p
and nice little depth effect, now you have to improve perfomance ;)
eg is this case in wm_timer really necessary?

[Mike Halliday]

Thats the spirit! - All joining in. hee hee

I will have a look at all your tries at this and see if it shows me where I am going wrong. Hopefully if we can get this sorted, Alain can add it as a function of the Game Designer bit of the IDE? - That would be nice to be able to have a new Gapi mode like ISO ha ha

Thanks for having a go at this guys.

M.

[c4esar]

Hi!
Got a first attempt, too.. Just turning with left/right, not moving, yet.

But I got stuck with calculating the used values in winmain before starting (suppose that's not possible?) and saving them in an array. Thought that might bring some performance?
Anyway I know there's some weird bulge in the front, but hopefully that one will disappear when I use correct maths instead of a simple multiplying factor. :rolleyes:


edit: well the search helped to solve my out of range error with that array..

[Mike Halliday]

Oh man! - This is sweet. - Sooo much faster then my code, and smoooth too! :)

Cant wait to see the forward and backward movement too! :)

Many thanks for participating in this thread!

Mike.

[Mike Halliday]

OK, Implemented c4esar's algorithm into my mapping test and the results are far more impressive than I ever expected.

Forward and backwards are smooth
Left and right need some work

Running at 640x480 though! :) - Check the attached image

Got a bit of an issue in that the map is projected in a different position than it should be! :(

My code is attached so you can have a look.

Mike.

[c4esar]

Wow! That's pretty cool!! :eek:
Wish I had a 640 x 480 device :( Always loved that Kart-game!
Thought you might want to have my code with new maths... Seems to be correct perspective now..

But I'm still working on the correct movement. When the player looks right, the whole map is turned, so the players x and y have to be rotated around the middle of the map the same amount of degrees (I suppose).

greetz, c4esar

[Mike Halliday]

Not run this on my device yet, but I bet it runs like a stuffed pig! hee hee

Will look at your new math and add it to my code! :)

We will get a Kart style game in PPL yet! - I am determined! ha ha

[Mike Halliday]

Wow! That's pretty cool!! :eek:
Wish I had a 640 x 480 device :( Always loved that Kart-game!
Thought you might want to have my code with new maths... Seems to be correct perspective now..

But I'm still working on the correct movement. When the player looks right, the whole map is turned, so the players x and y have to be rotated around the middle of the map the same amount of degrees (I suppose).

greetz, c4esar


Now your code is really cool! - I can see some of this being used in our retro demos too! :) - Your code is sooooo fast! I am really impressed!

Wonder if I can break it by making it 640x480? hee hee

M.

[Mike Halliday]

Oh, now this i cant believe. I get it running at 640x480 at 64fps when stationary and 32fps when moving??? Is this possible?

AAARRRGGGHHH - It even runs at 14fps FULL SCREEN at 640x480 on my PC! - ooooo

Ha ha - we are well on our way to retro-kart-ppl the game! hee hee

M.

[c4esar]

Hehehe, well that's fine! Can't believe it works... Maybe my wife made that code while I slept.. :D

[zehlein]

Ahhh, great stuff C4esar!! Really fast!
Only flaw is the rotation always rotates around the middle of the map and not around the player ...

[c4esar]

Yeah, but I hope to change that by moving the player's X and Y on a circle with radius = (distance of player to the middle of the map). When the angle of movement of the player equals the angle of turning the map the field of view should be the same as if the map turned directly around the player's coordinates. Or please tell me if I'm totally wrong ... ?

[zehlein]

I doubt it will work as expected, but *please* have a go on it and show us I'm wrong! Your version is by far the best we have at the moment :)

[c4esar]

Well.... I didn't work it out, yet, there are still some sinus / cosinus problems.
But here's my theory in detail, if s.o. wants to have a look at it - perhaps he/she can give me some advice..

[c4esar]

Yesss baby! It works finally...

[Mike Halliday]

Holy 'brown stuff'

This is awesome!

ALAIN!!! - we have mode 7 in ppl! lmao YEEEESSSSS!

One small point @c4esar - I crashed it when I moved around. (Think I may have pressed 2 keys at once maybe?)

Other than this small issue, this is magnificent! :) WELL DONE. a big hearty pat on the back!!!!

I have it at 640x480 on the PC at 35 fps!!! woo hoo. Kart games, here we come! :)

Mike.

[c4esar]

Same crash here... Sorry, I'm not used to that KeysPressed-managing.
Just wanted to check if left- or right-key is released. Perhaps you can help me with that?
And my engine works veeeeeery slow at PPC... :(

[Mike Halliday]

Same crash here... Sorry, I'm not used to that KeysPressed-managing.
Just wanted to check if left- or right-key is released. Perhaps you can help me with that?
And my engine works veeeeeery slow at PPC... :(

Sure I will have a go and see if I can work out why we get a crash. :)

Edit: - OK, so heres what I found. If you increase movement by 3 instead of 1 for up and down keys it does not crash! :)
The thing is, I dont know why!! lol

Movement speed of 3 seems more smooth on the PC too, so seems to be some sort of sweetspot value?

Have tested this on multiple track maps and its almost flawless.

Lets hope I can get a sprite on the map, then the real driving games can start! hee hee

M.

[c4esar]

Great Mike! Thank yor for checking that!! Looking forward to a real kart-game ;)
On my pc and on my laptop the hang always shows up at a turning of 180, 0 or 360 deg., even if I increase movement by 3.
But the strange thing about that is: sometimes there's no hang.
Can't figure out why, thought about a division by zero, but I didn't discover any.

OK, the hang won't happen if you don't leave the middle of the map. I think it's caused by the "acos"-function, because it caused several hangs before during tests..

Hey, I removed the '=' from the 2 terms 'if (playerx$ >= midx$)' and it works fine here, now..

[Mike Halliday]

Hmmm, not sure whats going on here.

I did (as a test) comment out all your turning code from WM_Keyup and WM_KeyDown, since then it has not crashed. Dont know how important these are to your code though!

I wonder how easy this would be to code in C and include with PPL as another surface?? - Any thoughts on this Alain?

[c4esar]

Yeah, I suppose it's the acos function... What I described above (my last edit) doesn't work..

[c4esar]

The turning-code is very important. The code has to know if there's already a turning process going on. Otherwise the starting angle for moving the player's coordinates has to be calculated new.
But I solved the problem on my machine by moving the calculating-code to the if clause in mainproc.
I attached the new code...

[Mike Halliday]

I can confirm that so far, this has not frozen when running! :)

It is a little slow when turning, then moving forwards, but I guess that this will improve overtime as we get to optimize the code some more! :)

This is definately a thread to keep watching now we have the basis of Mode 7 Games! :)

M.

[c4esar]

I suppose it would be quite difficult to calculate the changing x,y,z's for all sprites. That might slow down the game even more...
But I'm working on a new version, which I suppose to be faster and easier to handle.
It might even support different levels of height, but I'm not sure if I'm able to code what's in my mind.

[Mike Halliday]

Cool.

I have added a basic kart sprite, and a moving sky, but it needs a lot more work on my part - hee hee

Will have something next week to show i think! :)

[Mike Halliday]

Well, here it is, the first screen grab from the Mode 7 surface routine we have been working on, with sprite, sky and hazyhorizon! :D

Turning is still slow, but the concept is there. The kart sprite even turns left and right when you use the arrow keys!

More to come - I promise! :)

Mike.

[c4esar]

woohoo! that's looking great!

[Mike Halliday]

Still slow though, and unplayable on pocket pc devices even at over 500mhz! :(

Will try and get it faster! :)

[Mike Halliday]

OK, sussed the speed issue,

The smaller the map sprite, the quicker the thing runs.

I get 73fps when the map is only 400 pixels wide but 2048 pixels high.

Rotation is still a bit of a no-no, but again, the smaller the map the quicker the rotation is.

Check out the PC version attached! :)

Mike

[c4esar]

Yeeeeah! That's really fast!
But I guess if Alain will get to implement it as an "original" feature (if there's time for that after the ppl v.2 launch and everything) it will be even faster.
Didn't get far with my new idea until now... it's slow like #**.. :(
Perhaps I should try it in assembler? Do you know how to address a surface with asm?

[zehlein]

Perhaps I should try it in assembler? Do you know how to address a surface with asm?

Well, at least you can find out the address of the surface and use this with any assembler stuff you might like to (I wouldn't even dare to try but on the other side there is a nice little chapter on it in the PPL-book).

Have a look at the g_Lock entry in the help file and the LockInfo struct. Pretty intersting for direct bitplane manipulation!

[c4esar]

Thank you for your help, Zehlein! I'll have a look at it!:)

[Mike Halliday]

I'm with Z.

Would not even try ASM ... Its hard!!!

Not sure that it would speed things up much though as it is still using GAPI. I guess the only real way of speeding it up significantly would be to code using Direct X and let the gfx chip set do the drawing instead of the cpu!

Best of luck with ASM :D - I think you may need it! hee hee

Wish I knew C+, then I would have had a go at making a new Gapi surface mode! - Sadly I know zip about C+! :(

M.

[zehlein]

...
Not sure that it would speed things up much though as it is still using GAPI
...

M.

If he is working with the g_Lock and LockInfo struct there is no GAPI anymore. Rather simple POKE to the surfaces memory. It should be fast imho.

[Mike Halliday]

I meant using ASM might not speed things up. :) - If you could address the screen memory using ASM, that would be uber quick (or it should be) :D

Using G_Lock and addressing the surface memory directly may be quicker, but I recall that my Roto-Zoom example used direct surface addressing with Peek and Poke, and the downfall was getting to each pixel (X and Y loops) This I think is where PPL falls down.

It seems to take lots of CPU to do

for(x,0,scren width)
for(y,0,screenheight)
Poke screen address
end
end

Unless there is a quicker way to address the pixels it may be the same speed or slower?

Probably some tests would need to be done before saying which is the quickest!

M.

[zehlein]

Right, that's what I meant. Using ASM and writing to the surface directly.

[kornalius]

Peek's and Poke's are still running under the interpreter, even using g_lock. With the PASM and addressing the pixels from the g_lock, now that should be super fast, if you don't use PPL variables but ASM variables, (almost) pure assembly speed.

[Nicknack]

I have tried also to convert my version to asm, but I don't know how to manage negative and decimal values in asm :(
though the g_lock conversion shouldn't be too hard.

[c4esar]

Hey guys!
What I want to do is what Zehlein said. A function written completely in asm.
My plan is to create a simplified line-function in asm and to use this function to scan the surface by using direct adressing of the surface's pixels.
I would give x and y-values for the beginning of the line, its gradient and the step-value (number of pixels to skip because of perspective reasons) to that asm-function.
Then my function will 'draw' a virtual line on the map's surface but will set the obtained values on the screen's surface in a simple horizontal line.

Well I'm recognizing that my english lessons are lying far behind in the past.. :D Sorry!

x, y, step and distance values will be pre-calculated and stored in an array.
an alpha surface could be used as a parameter for the height of every pixel, to achieve a simple voxel-style (like in 'Comanche' e.g.)

@Nicknack: thanks for your example in the new thread ;)

[Nicknack]

sounds if you want to combine the bresenham line algorithm with my version of mode7 :D
I tried something similar, but it was too inaccurate in the final result. maybe you have more luck (or brain) ;)
I don't think this wil help you, because sin&cos are not asm-friendly, but here is the newest version of my original code. the old one I posted here had some mistakes and weaknesses

[zehlein]

For the sin/cos use, one could use a precalculated lookup-table. Should be easy enough to access in PASM.

[c4esar]

Wow, thank you!
I'll try my luck (lol, I thought this was a german expression) - even I'm not too optimistic ;) because I think you've been dealing with ppl much longer than me..
Anyhow this is a good way for me to learn!

[Mike Halliday]

Very fasy guys! :) - Height map voxels would be another interesting thing to have in PPL! :)

3D landscapes for flight sims etc!

Mike