Feel free, not fell.

And it looks good!

This looks very good and I'm glad to see more HP Prime development here now, especially games and such programs. I might give this a try on my calc later. Hopefully if it isn't fast enough there are ways to make it run faster.

Are you calculating a lookup table for each pixel of the screen?

Are you calculating a lookup table for each pixel of the screen?

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 ^^

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.

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.

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.

Actually Trailblazer isn't by me, but by MacBernick

As for Hpmuseum I'm glad they're switching to a new forum. Hopefully this solves the weird registration problem that disallowed freemail. However, keep in mind that most people there are against calculator games (or any other kind of non-educational calculator program), so getting feedback that isn't directly related to the source code or regular calculator usage might be hard.


EDIT: Btw I tried the new version and nice improvements. I also like the shadow effect below the ball. You should probably move the level track to the bottom part of the screen and add some sky, though.

By the way, is it me or that game reminds me of Plain Jump for the 83+? It was a 3D-looking game where you jumped from platform to platform with a ball.

Ooh that looks quite cool actually. Do you plan to add some animation or shadow for the ball?

Also, I like the gradient effect at the top. Did it impact speed when adding it?