Join us on Discord!
You can help CodeWalrus stay online by donating here.

HP FOR loops slowing things down?

Started by Dream of Omnimaga, December 25, 2014, 06:46:04 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dream of Omnimaga

Ok, so after some tests, it seems like on the HP Prime, if you decide to make a game utilizing tilemaps, then if you want a fast speed but need to update the entire screen every frame for whatever reason (eg a parallax background), you will need to pre-render the entire level map into a massive GROB, then only draw the 320x240 chunk you need on top of the background. That's unless, of course, you don't need to redraw the entire map every frame (in which case it should be much faster).

Otherwise, from this code, which fills the screen with one tile every frame:

WHILE 1 DO


BLIT_P(G9,0,0,320,240,G3,0,0,320,240);
FOR mapTileX FROM 0 TO 320 STEP 16 DO
FOR mapTileY FROM 0 TO 240 STEP 16 DO
BLIT_P(G9,mapTileX-A, mapTileY, mapTileX+16-A, mapTileY+16, G1,112,0,128,16,#666666);
END;
END;
A := A+1;
IF A>16 THEN
A := 0;
END;

BLIT_P(G0,0,0,320,240,G9,0,0,160,120);
END;


This is how fast things will get:




The massive GROB pre-rendering method might cause some issues if you run into that one nasty HP Prime bug that causes some large GROB to not work properly, though, so I'll have to experiment. That said, it would be a more ideal situation since I wouldn't need to render the level every frame.


Another thing that could be done is checking if without a FOR loop it's faster (eg by using one BLIT command for each tile (336 of them). If it is, then it means this calc has the same problem as the 83+ had with TI-BASIC, where inverting the entire screen using 5985 Pxl-Change() commands instead of For(A,0,95:For(B,0,63:Pxl-Change(A,B:End:End was over twice faster.

For simple games this might not be a serious issue, though, but for more complex games that requires complex and pixel-accurate physics that could cause issues.

You could always use frame-skipping, though.

Anyway I am slowly implementing map rendering into the game now.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Duke "Tape" Eiyeron

(I didn't understood the pxl change problem for 83+)

You could try having smaller submaps globs to redraw when you need tjem and refresh when their geometry change. That and Quadtree could get quite along.
  • Calculators owned: A lot.

Dream of Omnimaga

Pxl-change inverts the pixel color on the 83+.

Also what do you mean by quadtree?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Duke "Tape" Eiyeron

Qudtree is aethod to improve collision collision performances. When you have to check for each pair of objects to check if they collide, you can split the world in smaller area and track thearea they are inside. Thus you don't have to check all the objects, just the locally near.
  • Calculators owned: A lot.

Dream of Omnimaga

#4
Oh ok, yeah I was planning to do something similar actually. Also if collision speed became an issue I could just render and check enemies that are in the screen and only render 3 max at once in the screen like in some SNES games.


EDIT: Also, while pixel-based map data is nice for map storage and editing, it seems like it could make collision and map display much more cumbersome. When pre-rendering the map data I might also copy it in a list so that it's easier to work with (and edit).
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

maybe it's this slow because you are reading pics ? That sounds very likely.

Dream of Omnimaga

I am unsure. It could be very possible, though, plus the fact that graphical buffers can be any size in width.

On the 83+ tho I once made a shoot-em-up in pure BASIC where I used 1 output command per ship (16 total IIRC). It was very large, but if I had used two For loops it would have been about three times slower. That's how bad TI-BASIC could be.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Lol yeah TI basic is slow as hell. Doesn't mean the prime has to be that slow tho.

Duke "Tape" Eiyeron

Eyup, FOR are mostly slow because sometimes the parser needs to go backwards in the code. I don't know why it would be slow but there's my idea.
  • Calculators owned: A lot.

Dream of Omnimaga

Quote from: Streetwalrus on December 30, 2014, 12:27:34 PM
Lol yeah TI basic is slow as hell. Doesn't mean the prime has to be that slow tho.
Well, it can at least be proportionally slower than not using For. As in, if for example it's 4 times slower in BASIC, maybe it will also be 4 times slower in HP PPL. It's just that HP PPL is so fast in the first place that even with such slowdown you can still make almost any type of 2D game.

You can also do frame skipping anyway. I tried with my program above to only draw every 4 frame and it was blazing fast.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Good to know. You still should try to store the map in a different way though. :)

Dream of Omnimaga

#11
I'M planning to store it all into one massive picture, along with a second copy in list format. Lists will make it much easier to display it and collision. However, displaying or storing the massive pic might be a problem due to an HP PPL glitch with large images (which happens after running many programs that use such stuff).

If the program runs fine that way before running anything else, then I had an idea in mind though: Have the game pixel-test one part of the screen to check if map is drawn properly, and if it isn't, then it would show a warning text telling you to press ON+SYMB to fix game. Kinda like that TI-84+ BASIC trick that checks if the extra Text() row glitch was triggered (I think it was Pxl-On(6,0:Text(1,1," ":If not(Pxl-Test(6,0:DispTable )
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Dream of Omnimaga

#12
Ok so I tried again using a pre-rendered level image and background. The background is 640x240 and the foreground 960x240. This is how fast it gets (although it's smoother on-calc, scrolling by 1 pixel at a time):



Fun fact: those images are about 30 KB total in size, using the ICON (PNG) format. In HP's proprietary format, they're over 1 MB :crazy:


EDIT: I had the FOR loop set to increment scrolling offset by 0.5 instead of 1. Re-uploaded new screenshot now, which is twice faster.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Cool !
Also, since each nibble takes two bytes it's kinda normal that the data is 4x bigger lol.

Dream of Omnimaga

There is also the issue about HP PPL using unicode for the source, so one character is like 2 or 4 bytes. Basically, a 16x16 sprite in HP PPL format can take about 512 or 1024 bytes of space. In PNG it really depends of how complex the image is.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Powered by EzPortal