Feel free, not fell.
And it looks good!
Are you calculating a lookup table for each pixel of the screen?
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. :)
FOR ray FROM 1 TO 119 DO
BLIT_P(G1, IP(x1Table(ray, col)), ray + 10, IP(x2Table(ray, col)), ray + 11, G2, texX1, texOffset, texX2, texOffset + 1);
FOR ray FROM 1 TO 119 STEP 4 DO
BLIT_P(G1, IP(x1Table(ray, col)), ray + 10, IP(x2Table(ray, col)), ray + 14, G2, texX1, texOffset, texX2, texOffset + 1);
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.
You should probably move the level track to the bottom part of the screen and add some sky, though. :PMy first idea was to lower it a bit and add a starfield at the top, and the dashboard at the bottom. There's only two values to be modified in doRender() to do that (ray + 10 and ray +14). But a sky, as tiles now look (a bit) like mud and grass, why not...
Actually Trailblazer isn't by me, but by MacBernick ;)I don't know the 83+ scene at all, but I wouldn't be surprised. This game is a 8 bits classic and there have been a lot of clones running on many plateforms.
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. :D Do you plan to add some animation or shadow for the ball?Yep I have plans to animate the ball, most likely rendering something quick in a few steps with Blender.
Also, I like the gradient effect at the top. O.O Did it impact speed when adding it?
FOR r FROM 10 to 20 DO
FILLPOLY_P(G1, {{0, r}, {319, r}, {0, r + 1}, {319, r + 1}}, 0, (20 - r) * 255 / 10);
END;
Wha, this is looking pretty awesome, keep up the great work! :D
By the way, just a suggestion to complete my other post on the other page: Would it impact performance if under each floor tile just in front of holes, you added a small wall to give the effect of depth to each floor tile? That said, there would be the issue about diagonal walls, though >.<
EDIT: I got an idea: Just BLIT_P two copies of the race track (with 4 and 8 pixels offset vertically respectively) then apply a black polygon over it with 70% opacity, then display a 3rd copy of the race track on top of everything, with the ball and other stuff. Make sure to set empty spaces as the transparent color. This would be enough to give a depth effect:
(http://img.ourl.ca//tbsc.png)
Or you can display them at a slightly smaller zoom, but this would slow the game down.
EDIT 2: I just tried it on calc with your older program and I still get 16 FPS most of the time. However, keep in mind that that program wasn't full screen and I did not try with zooming.
Good. I had originally done the naive per pixel look up table when writing my Nspire mode 7 engine, but I also came across a similar method. Instead of storing the start and end positions for each scanline, I stored the start position and a vector to increment the position by each pixel. I don't know the performance penalties for different calculations in HP-BASIC, but a vector addition per pixel should be cheaper than a vector linear interpolation (which involves multiple additions and multiplications) each pixel, so you may want to try it.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().
I see what you mean. But here, as screen lines are always parallels to lines of texels, the BLIT_P function of PPL does this for me even faster. Nothing is computed at pixel level in fact : BLIT_P scales and copies on screen a whole line of a tile at once.Ah, so it will scale the textels automatically for you? That's even better.
From what I remember, diagonal arrow keypresses work on the real calc, but I'm unsure if multiple keypresses where one or more of the keys isn't an arrow will work. The 84+ BASIC add-in xLIB had the same problem, where the only multiple keypresses supported were with arrows.
Btw I tried the last version on-calc and it ran at 14-16 fps. However I can't figure out what's the jump key. D:
Ah, so it will scale the textels automatically for you? That's even better.
Yep, basically I'm pretty sure that anyone with the knowledge would be able to generate a raycaster from it and even with textures it would still run faster than the non-textured Lua one for the Nspire.I see what you mean. But here, as screen lines are always parallels to lines of texels, the BLIT_P function of PPL does this for me even faster. Nothing is computed at pixel level in fact : BLIT_P scales and copies on screen a whole line of a tile at once.Ah, so it will scale the textels automatically for you? That's even better.
Actually it seems like the version you posted now is 14 FPS only at the beginning of the track where there's no hole at all in the floor. I notice right now that in certain parts, such as the Hello World part, I get up to 23 FPS (I even peaked at 27 once). But yeah, when I made my HP 39gII Tunnel game, it seemed like for loops and some maths slowed my game down more than any complex graphics. That said, on the HP Prime, sprite scaling/zooming isn't very fast either. You can display like 10 BLIT commands that are 320x240 pixels large and barely see any speed difference, but the minute they are stretched up by one pixel, it gets much slower.
For 3D games I personally prefer just working on a 160x120 GROB then once I am done drawing everything there, I use BLIT_P(G0,0,0,320,240,G1,0,0,160,120). I wouldn't even mind doing using 96x64 stretched up to 288x192 with a frame around the screen for particularly complex 3D scenes with textures, since most people are used to old calculators with screens this small anyway.
That said, 15 FPS wouldn't be too bad per 3D standards IMHO, as long as it's not some sort of game where you move on ice and slip a lot, since it would then be very hard to control. For a plain jump game it would still be very enjoyable, plus some N64 games without the Expansion Pak sometimes ran at slower frame rate anyway (Mystical Ninja Starring Goemon, I'm looking at you).
Yep, basically I'm pretty sure that anyone with the knowledge would be able to generate a raycaster from it and even with textures it would still run faster than the non-textured Lua one for the Nspire.
You can also do some interesting animations with BLIT_P scaling, like the fade in pixel effect and wavy text in http://img.ourl.ca//ssballfadein.gif , not to mention saving some space by displaying certain graphics larger than they really are.
By the way, to generate the floor, do you think that simply generating it in 2D with no stretching (with the textures displaying as 32x8 PNGs not stretched up) , then generating a 3D floor from it would be faster than calculating everything tile by tile?
I like the new track and graphics. It looks very nice. I also like how the ball appears below the track, it looks good when falling down. Also lol it's quite hard actually. Hopefully the final version has multiple levels with different difficulties. :P
Just a few things:
-Do you ever plan to move the track at the bottom of the screen and add a sky at the top with an HUD? It might look more polished/professional that way, else people might think the game was rushed if it remains with the bottom half of the screen nearly empty.
-If BLIT_P(G1, xEnds(ray, 1), ray + 20, xEnds(ray, 2), ray + 24, G4, 0, (rayTable(ray) + camPosition) / 8, 160, (rayTable(ray) + camPosition) / 8, #FF00FF) is changed to BLIT_P(G1, xEnds(ray, 1), ray + 20, xEnds(ray, 2), ray + 22, G4, 0, (rayTable(ray) + camPosition) / 8, 160, (rayTable(ray) + camPosition) / 8, #FF00FF), it could slightly improve speed, but then you lose the 3D effect. I would show you an idea to do a 3D effect, but sadly the emulator doesn't like my code (Whitespace bug).
-I get error invalid input at the end of the track.
You may be able to improve the speed by a large amount by switching to MAKELIST or MAKEMAT commands rather than appending elements to an existing list, etc.
I wonder if it could explain why sometimes the jump key isn't very responsive (eg if you don't press Enter long enough).