Calculator Community > HP Prime
[WIP] Trailblazer Prime
fb39ca4:
Are you calculating a lookup table for each pixel of the screen?
DJ Omnimaga:
Wow I just tried this on calc and it's pretty impressive. What I notice is that in certain occasions it runs at a relatively good frame rate per calculator standards (being used to TI-84 Plus assembly games), but in other occasions, it suddenly slows down a lot. I would say that the frame rate varies between 4 and 10 FPS approximately. I didn't have time to check the code, but do you actually run through a tilemap then display each line at a different zoom to create some sort of mode 7 perspective? I was surprised to see the floor being textured with stuff other than plain squares.
Anyway good job so far. Hopefully there is a way to make the speed more consistent. :)
EDIT: For raycasters, at first it would be better IMHO to experiment with the RECT_P command or something, then maybe sprites.
Also I wonder if lowering the resolution would help? (for example, in my pseudo 3D program, I used a stretched up 160x120 GROB).
Also to distribute programs, you can go to C:\Users\<username>\AppData\Roaming\HP_Prime (or whatever HP Prime folder you currently use) then copy the .hpprgm from there into a zip file. :)
MacBernick:
--- Quote from: t0xic_kitt3n on December 12, 2013, 10:32:53 pm ---Are you calculating a lookup table for each pixel of the screen?
--- End quote ---
Not for each pixel. I use three tables :
rayTable stores the distance to the rendered plane for each screen line,
x1Table and x2Table are lists of lists of projected horizontal starts and ends of each square, for each screen line again.
Those are computed in init().
The track is stored in trackMatrix, it contains textures index for each square (0 for a hole).
Using rayTable and the camera position allows to find which row of trackMatrix is displayed at a given line. A modulo gives the texture line to display. x1Table and x2Table are then used in a BLIT_P to scale the texture line to achieve the projection.
Note that because the projection start from far to near (up to down, screenwise), the textures are actually reversed. I'll adress this later, if I'm to keep texturing anyway.
I hope it makes sense, it's not hard to understand, but not easy to explain ^^
--- Quote from: DJ Omnimaga on December 12, 2013, 10:36:01 pm ---Wow I just tried this on calc and it's pretty impressive. What I notice is that in certain occasions it runs at a relatively good frame rate per calculator standards (being used to TI-84 Plus assembly games), but in other occasions, it suddenly slows down a lot. I would say that the frame rate varies between 4 and 10 FPS approximately. I didn't have time to check the code, but do you actually run through a tilemap then display each line at a different zoom to create some sort of mode 7 perspective? I was surprised to see the floor being textured with stuff other than plain squares.
Anyway good job so far. Hopefully there is a way to make the speed more consistent. :)
EDIT: For raycasters, at first it would be better IMHO to experiment with the RECT_P command or something, then maybe sprites.
Also I wonder if lowering the resolution would help? (for example, in my pseudo 3D program, I used a stretched up 160x120 GROB).
Also to distribute programs, you can go to C:\Users\<username>\AppData\Roaming\HP_Prime (or whatever HP Prime folder you currently use) then copy the .hpprgm from there into a zip file. :)
--- End quote ---
Thanks for your feedback. I noticed framerate variations in sim also, I was hoping it wouldn't be the case on the real machine. I don't know from where it comes. Maybe some garbage collection. Note that the more holes (black squares) you have on screen, the less loops are done. May be an explanation too.
I first used lines to draw. If you uncomment the LINE_P call at line 63, and comment out the BLIT_P from line 64 to 73, you'll get the same with plain squares instead of textures. But with very little framerate improvement unfortunately. At least on the sim.
I know I can distribute the .hpprgm file, but I have nowhere to upload it ^^ Maybe I will try on my webserver for next release, it has very limited bandwidth but this is not a big file, I guess it should be OK.
DJ Omnimaga:
If you click the Reply or quote button, below the text form you can upload files actually. Of course, at 40 posts you can also upload a link to the file in Omnimaga downloads section as well. Else, there is Cemetech, TI-Planet and Hpcalc.org, but Hpcalc.org can take about 6 months before approving your files.
EDIT: I modified your code so that instead of
--- Code: ---FOR ray FROM 1 TO 119 DO
--- End code ---
--- Code: ---BLIT_P(G1, IP(x1Table(ray, col)), ray + 10, IP(x2Table(ray, col)), ray + 11, G2, texX1, texOffset, texX2, texOffset + 1);
--- End code ---
I have the following:
--- Code: ---FOR ray FROM 1 TO 119 STEP 4 DO
--- End code ---
--- Code: ---BLIT_P(G1, IP(x1Table(ray, col)), ray + 10, IP(x2Table(ray, col)), ray + 14, G2, texX1, texOffset, texX2, texOffset + 1);
--- End code ---
Although the graphics don't look as great, it's a lot smoother and the frame rate seems consistent now.
At STEP 2, the framerate is pretty good as well and graphics aren't affected much, but you notice a slight drop in performance when there aren't any holes on the screen.
EDIT: This is how it looks like at 4 pixels intervals by the way:
(Although I don't recall seeing all those weird single horizontal lines before on the real calc, so this must be the emulator's refresh rate. The white/gray tiles don't look great under such low resolution even on calc, though)
MacBernick:
Oh I thought the 40 posts limit applied to attached files too. I'll use it next time then, great !
You are basically dividing the vertical resolution by 4 here. Which is better than dividing it by 2 in both direction I think, because there is far more iterations in the vertical way than in horizontal. That's the kinds of thing I didn't want to do in the first place, because I wanted very readable symbols on the tiles. But I changed my mind about that. First, maybe instead of stretching a single texture line to 4 pixels high, actually blitting 4 lines of texture at once would maybe give a better visual result (but not sure about that though, have to test). Second... why readable symbols anyway ? Contrasted but fine 16 bits textures would be even nicer, and would not impact performance at all. Yes I think I will retain this solution. Need to clean up init() now because it is doing 4x more work it should do ^^
I've implemented your fix as is for the moment, plus some other features, updating the first post right now.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version