0 Members and 4 Guests are viewing this topic.
You should probably move the level track to the bottom part of the screen and add some sky, though.
Actually Trailblazer isn't by me, but by MacBernick 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?
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!
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: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.
Quote from: t0xic_kitt3n on December 12, 2013, 10:32:53 pmAre 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().
Are you calculating a lookup table for each pixel of the screen?
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.
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.
Ah, so it will scale the textels automatically for you? That's even better.
Quote from: MacBernick on December 15, 2013, 06:45:54 amI 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?
Author
Topic: [WIP] Trailblazer Prime (Read 43563 times)
