Does it work ?

thanks ^^

Thank you. I still have important things to do at work so my progress on this is slower and my answers shorter, one week to go like this I guess.

I don't know what's the best place to put it, just do as you think it is best. I came here in the first place because a search engine drove me to the Prime Hack thread, as people in this forum seem to be cool I decided to post my project here, but I admit I didn't think about where exactly it would fit best.

I spam amazon twice a day about my lost-in-post Prime, with no success atm. If I have no news in a few day I'll go for a refund and order it somewhere else. Oh and I saw a ti84-plus CSE at quite a good price (those little things are really expensive here in France) on another www site, I ordered it today too ^^ Is there any good (and accurate :p ) emulator for this one yet ? I tried a 84-plus SE (not C) emulator (was Wabbit the name ? something like that) that seems good, those two machines are quite compatible I guess ?

Hey it seems to work not bad at all. Thanks again for feedback.
Updating first post with new versions, some tiles are working, but jump is disabled for now.

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.

Let's call it Not Too Bad. Working on sim only is not ideal at all. Writing to Amazon right now to ask where the #@! my calc is stuck. Should have been here for one week at least now.

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).

What I'm thinking right now is that this machine would have enough horsepower to run the first Unreal full res @60fps... If only we could have access at least to some internal calls, a SysPPL just like we had SysRPL on the 48. Please HP, pretty pretty please ^^

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.

What I've done here is precalc raycasting for the vertical lookup already, and more traditional projection for the horizontal (no yaw control so no need for trigo here). The only knowledge to have is that, in a right rectangle(EDIT : triangle, obviously), TAN α = opposite / adjacent. And that's really it. Then it's a matter of playing with length and angles, and tedious optimization. I may write a how-to on the subject one day if people are interested. Be aware that a complete raycasting engine would not allow to precalc tables as much as here, so maybe don't expect more than 2 FPS ^^' (but lowering the resolution would have a better impact though).

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?

Yes it would divide the number of iterations by 5. I'll definitely try it.


Other subject : I've just found out that TI has made some z80 based calc with machine language official support (yep, I didn't know... Maybe I'm too old for this stuff now ^^'). Are they still available ? As z80 ASM is the first I learned, and I was quite good at it well... more than 20 years ago, I'm pretty sure I could run this engine faster on the z80 than on the Prime ! I'm considering buying on maybe at the beginning of next year.

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.

One quick question : on the virtual calc, when you press two or more keys at the same time, only the last pressed key is actually active. Is it the case on the real calc too ? It could be a problem here since three keys could be pressed together if you want to accelerate, jump and move at the same time.

You should probably move the level track to the bottom part of the screen and add some sky, though.

My 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
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.

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.

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?

Yep I have plans to animate the ball, most likely rendering something quick in a few steps with Blender.

The code for the gradient is quite straightforward :

  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;
This FILLPOLY fuction seems to be really fast even with alpha blending, and only 10 iterations does not impact that much on performances. I can barely tell the difference on the virtual calc.

Wha, this is looking pretty awesome, keep up the great work!

Thank you

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.

I thought about some sort of gradient to give some deepness to the holes, but this is even better, you have great ideas for the game . Not sure if there is not something more efficient than drawing multiple copies of the track though. Maybe yet another precomputed table could easily store for which tiles  the last line of texture should be blended beneath.

I attach an intemrediate version here, since I was doing jump function when some friends suddenly came with beers so well... at least I started it ^^'
I'd be glad to know how framerate is improved on the real Prime.

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.