Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Matrefeytontias on December 25, 2012, 04:27:00 pm
-
Hey guys,
I made a kind-of mode 7 test (pretty ugly) and I thought I could post it here.
It's Axe → slow.
It takes Pic0 and projects it in Mode 7 style (rotate with left / right). No screenshot because Axe 1.2.1 crashes wabbitemu.
Oh, and it's REAAAAAAALLY ugly.
-
What is mode 7?
-
Originally, it's an integrated circuit of the SNES to display backgrounds or tilemaps with a perspective effect (see F-Zero or Mario Kart). The name remained and now is the name of the effect.
-
Oh, nice, so that is a 3D tilemapper? O.o
-
It was actually originally intended just for displaying scaled/rotated tilemaps. However, changing the rotation/scale values at each scanline allows displaying a perspective effect.
The idea is that texture mapping a plane perpendicular to the screen has each consecutive texel in the scanline spaced apart by identical intervals. The trick is that for each "line" on the screen, you calculate the texture coordinates of the center of the scanline, then get the leftmost coordinate in the scanline using the calculated pixel interval, then add the pixel interval for each pixel in the scanline and get the pixel color at each coordinate. Hopefully this was somewhat comprehensible :P
-
I might give this a try soon. I'M interested at how well Mode 7 (with full rotation, unlike Quigibo's version) runs in Axe.
-
Calc84maniac, I sent you a PM about that :P
DJ_O well, this program isn't really an example, I'm a total newbie with that.
-
Screenshot please? I don't have axe on my wabbitemu.
-
I can't, Axe 1.2.1 crashes Wabbitemu, so if someone could make a screenshot it'd be great :)
-
I noticed one version of Axe crashed WabbitEmu, but it wasn't 1.2.1a for me.
EDIT I get ERR:INVALID TOKEN when compiling O.O
If pxl-Test(Sx/256) and Xmask,Sy/256 and Ymask,P)
That is where the error points too ???
-
I think Matrefeytontias used a computer tokenizer to create the 8xp, which turned the letters "Sx" into the statistics token 'Sx'. You can fix these fairly easily by hand, I think there were only two issues.
-
Oh wait, it's an Axe-only token? I guess that explains it then (since computer tokenizers don't recognize them). EDIT Nvm I got your msg the other way around.
-
No, the issue is sort of the other way around. 'Sx' is a statistics token that apparently the computer tokenizer he used recognized, so it converted his references to the custom variable he named "Sx" into a token that Axe doesn't recognize.
-
I totally forgot Sx existed lol. That tells how much I used my calculator for math classes.
Now his program just displays Done ???
EDIT Nvm forgot I needed Pic 0. Now it just displays the graph screen, then when pressing ENTER, the screen turns blank and hangs. D:
-
I'm not sure it's hung... try holding down CLEAR for a good second or so. The program only checks keys between frames, and frames can take a long time (almost a second) to render. And the blank screen may just be a fully white image (like a portion of the graph screen) displayed in mode 7.
-
Wait it works now. I just used a pic0 with almost nothing displayed in the area where it rotated. And the framerate was a bit low. I got it to work now and here's a screenshot.
-
I'm trying another technique, I'll post a screenshot (maybe) and a source (surely) once done.
-
Cool to hear. I can't wait to see how it looks like :)
-
I can't believe it myself ... perfect Mode 7 ! O.O
With this new (and in fact, simpler) method, you have the choice between super-beautiful and awfully slow mode 7 :
(http://mattias.refeyton.fr/espace-ti/mode7/mode7_res1.gif)
Or super-fast and awfully ugly mode 7 :P :
(http://mattias.refeyton.fr/espace-ti/mode7/mode7_res4.gif)
I switch between these speeds by modifying the resolution. (sources for these 2 programs attached)
-
Very nice! Great job!
Are there any other potential optimizations remaining?
-
Very nice, but how come it is so incredibly slow in the 'beautiful' mode?
-
Wow, this is pretty awesome, congrats! :D
-
Thanks everyone :)
Very nice, but how come it is so incredibly slow in the 'beautiful' mode?
It's because of the resolution : in the "beautiful" mode, I draw the scene pixel by pixel, which 96*32 calculations (see the source to have the real numbers), and in the fast mode, I draw the scene with 4*4 squares, so I do 16 times less calculations - but it's pretty ugly.
-
I'm impressed with how small your code is.
Have you toyed with the idea of a look-up table? I know it is a lot more "code", but usually they are much faster -- and you need brute force speed here.
For example... The top line looks as if only 50% of the pixels tested are actually being drawn. So why test all of them? The table could contain the pixel offsets you might test as well as hold some intermediate precalculated values.
Very impressed!
-
That doesn't look quite like correct perspective, how are you going about doing your mode 7?
-
@Ranman I said I do 96*32 calculations, not 96*64. I test (and draw) only the bottom half of the screen. And I coded this around 2 am, so I'll optimise it right now :P
@Builderboy if it's not perspective, I don't know what it is. All the engine works around these formulas :
screenX = X / Z
screenY = Y / Z
Add some scaling and offsets, and you got it.
-
@Ranman I said I do 96*32 calculations, not 96*64. I test (and draw) only the bottom half of the screen. And I coded this around 2 am, so I'll optimise it right now :P
I think you misunderstood me... The top line (@32) where you first start drawing looks to have half as many physical pixels drawn as the bottom line (@63). Or you could look at this way.... the bottom line may have half as many pixels tested as the top line (@32).
Optimizing can be a whole heckuva lot of fun! :)
-
Oh I see :P
It's because of my image. Try my program with a Pic0 full of pixels (like a full ground or something), there are as many pixels on the line 32 than on the line 63, it's just that the pixels of the line 32 are "further" than the ones of the line 63.
-
It's because of my image. Try my program with a Pic0 full of pixels (like a full ground or something), there are as many pixels on the line 32 than on the line 63, it's just that the pixels of the line 32 are "further" than the ones of the line 63.
I got ya... If you put these "pics" in a 2D array (like a tile map) you'll be drawing all pixels. Maybe my idea wasn't so good after all. LOL
-
Well, I looked at the source again, I can't see anything optimisable ; I can't find anything that can be precalculated and put into a LUT ; and I can't think of a simpler method. Maybe Mode 7 is not for Axe :(
-
Do you have a screenie yet? I heard on irc yesterday you were able to optimise it with a LUT
-
Yeah, in fact I was able to optimize it a lot. And it allowed me to implement rotations ! :D
The program of the screenshot uses 3 LUTs : one for the Y coordinates, one for the X coordinates (this means all the screen, because X coordinates depend on Y ones) and one to hold sin and cos values for the 256 angles. Oh, it also uses Full (because I don't want to make the screenshot during all the day ;D )
So, let's make our first lap of circuit using Full and 3 LUTs with a resolution of 2x2 pixels !
(http://mattias.refeyton.fr/espace-ti/mode7/mode7complete_res2_full.gif)
-
Wow, awesome :)
But as you said yourself, maybe mode7 isn't something for axe, or maybe there still is some optimization left you didn't realise, because it's still quite slow xs
-
Yeah, I think Mode 7 is more for ASM or another calc. Even with that, now that I have the method I can apply it for different platforms or languages.
<right now I'm trying it with Nldess, but shhhhht :P >
-
Is there a possibility of detecting a white pixel early so you can skip the calculations and move to the next? Seems to be a lot of whitespace in that track.
-
I don't think, because I need to make the calculation in order to know where to test the blank pixel ...
-
Wait, so you start with the projected location, and calculate back to the position in the image? Am I correct here?
-
That's it plus one thing : I start with screen coordinates and a z-location (which is not part of the screen), and I use them to retrieve the coordinates of the pixel of the image to be displayed.
-
Is that the usual way of working with mode7, or is that your interpretation? Because that sounds kinda strange to me
-
I don't know, I didn't use any tutorial for this method. My thought was that instead of going through all pixels of the image, project them on the screen and then have several dots on the same pixel or a pixel left blank, I should go through all pixels of the screen and retro-project them on the image, so in that way all the pixels will have their corresponding texture point.
-
Well, if you look at it that way, it makes sense too. I wouldn't really know which one is faster though
-
I think projecting pixels from the buffer onto the screen would be faster, you don't need to project empty regions at all.
But calculating which (screen-)pixels have to be set for one (image-)pixel/texel needs some time, too.
Many clear texels -> image->screen faster
Many set texels -> screen->image faster
Also, are you doing real mode 7 (which doesn't support perspective/z at all)?
-
In fact I don't use Z perspective : I just use a pseudo one to make the lines at the top of the display area look further (I didn't found any other method). And I think your comparison is right, I'll try another technique.
-
Yeah, in fact I was able to optimize it a lot. And it allowed me to implement rotations ! :D
The program of the screenshot uses 3 LUTs : one for the Y coordinates, one for the X coordinates (this means all the screen, because X coordinates depend on Y ones) and one to hold sin and cos values for the 256 angles. Oh, it also uses Full (because I don't want to make the screenshot during all the day ;D )
So, let's make our first lap of circuit using Full and 3 LUTs with a resolution of 2x2 pixels !
(http://mattias.refeyton.fr/espace-ti/mode7/mode7complete_res2_full.gif)
Wow, this is looking awesome IMO, epic work! :D
-
Now include some cars and you have it: Super Mario Kart on a calculator!
It's not yet possible on ndless
-
It's not yet possible on ndless
LOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL :P
You already have Doom on Nspire. Mario Kart is nothing.
And also :
(http://otbp.tifreakware.net/images/fzero8.gif)
F-Zero z80 by calc84maniac
-
ROFL
Only the Gameboy can be emulated (which supports mode 7, but only mario kart: super circuit (which is crap) runs)
You already have Doom on Nspire. Mario Kart is nothing.
I hate Doom, Wolfenstein 3d.. Something like Monkey Island would be cool (OT, I know)
-
ROFL
Only the Gameboy can be emulated (which supports mode 7, but only mario kart: super circuit (which is crap) runs)
What do you mean ? It's not an emulator. http://www.omnimaga.org/index.php?board=26.0
-
Nope, I referred to the nspire: gpsp.
-
Oh, I see. But you can see here that the Gameboy is not the only platform capable of Mode 7.
-
I see, F-Zero uses Mode 7 too..
It's way faster than yours, is it asm?
-
wow, that is quick and running smooth O.O this is AWESOME! :D
-
Welcome in the world of ASM.
I think I'll try to make something similar, but seeing my ASM skills, I'm afraid that I won't get anything until a year or two D:
-
If you make it your goal, it would be a great exercise to increase your ASM skillz.
-
Yeah, but considering how low are my skills, I don't even know if I'll finish it someday :P
But I'll try anyway.
-
I see you have been asking about fixed-point maths. There really isnt a great deal to mode7 when its broken down, i rekon you could do it even if it isnt super optimized to begin with.
My suggestion is to become more familiar with the hardware at a low level (LCD access, memory structure etc) and also making small test programs for fixed-point operations (to simulate the individual aspects of a mode7 engine) before finally bringing it together.
-
Yeah, of course I didn't think of getting directly into Mode 7 :P
-
Oh, I see. But you can see here that the Gameboy is not the only platform capable of Mode 7.
The Game Boy and Game Boy Color don't support Mode 7 as far as I know. The Game Boy Advance, on the other hand, does. And if a platform like the Nspire can run Doom, then it can easily run a Mode 7 engine (in fact there is one for Ndless 1.0, which is very smooth).
On the 83+ Mode 7 is fully possible since Calc84maniac did it, as shown above, but not an entire Doom port. However, Axe is much slower than ASM for it since it's a much higher level language. I bet there can be speed improvements, though, but nowhere close to what ASM can achieve. (Unless someone makes an Axiom)
Back on topic, this looks quite nice Matrefeytontias. You might want to make the lines surrounding the road thicker on the small map, though (so it doesn't look like a dotted line at times)