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:
(https://img.ourl.ca/hpscrolling.gif)
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.
(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.
Pxl-change inverts the pixel color on the 83+.
Also what do you mean by quadtree?
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.
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).
maybe it's this slow because you are reading pics ? That sounds very likely.
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.
Lol yeah TI basic is slow as hell. Doesn't mean the prime has to be that slow tho.
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.
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.
Good to know. You still should try to store the map in a different way though. :)
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 )
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):
(https://img.ourl.ca/walrii2.gif)
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.
Cool !
Also, since each nibble takes two bytes it's kinda normal that the data is 4x bigger lol.
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.
UPDATE: Why didn't I think about the following before? :banghead:
I previously said that if when scrolling I only updated the needed row or column of map tiles, I would not be able to use parallax scrolling. Well, I am wrong, because what I forgot is that since the HP Prime has transparency, then I can simply keep the background and the current 336x256 map area separate then draw the new tile columns in the map buffer. So I just need to update the map separately then re-paste the result over the background every frame.
By the way, when the first demo with a fully functional level comes out, I might start releasing the source publicly and cross-posting on other forums. Hopefully if the game runs fast enough, perhaps this speed, and the fact I plan to make the engine run at the same speed on both the hardware and emulator, could give people incentive to develop games using the emulator even though they don't have the calc itself?
As I found out in my speed testing, MAKELIST should be faster than FOR loops (unless the lists generated and thrown away take up too much memory, so testing is still needed). So, I suggest you try this to improve speed, perhaps:
WHILE 1 DO
BLIT_P(G9,0,0,320,240,G3,0,0,320,240);
MAKELIST(MAKELIST(BLIT_P(G9,mapTileX-A, mapTileY, mapTileX+16-A, mapTileY+16, G1,112,0,128,16,#666666),mapTileY,0,240,16),mapTileX,0,320,16);
A := A+1;
IF A>16 THEN
A := 0;
END;
BLIT_P(G0,0,0,320,240,G9,0,0,160,120);
END;
EDIT: I also wonder if replacing your A:=A+1 code with A:= (A=1) MOD 16 and ditching the IF would be faster. I don't know.
My brain just melted *.*
I'll be sure to look at MAKELIST more, though, if I can figure out how it works. I tend to have an hard time deciphering how some instructions work sometimes. >.<
By the way, I just tried the code on the first page with only 1 row of tiles (20 total) and I got about 105 FPS. With 2 rows (40 tiles) I got roughly 70 FPS. So by using the scrolling method where you only draw the necessary map rows/columns and shift the rest of the screen around, frame rate should be more than good. And if someone wants to make a Sonic game he can simply add some frame skipping to speed things up even more.
Whoa, parallax scrolling?! O.O
The HP Prime is looking like a very interesting development platform.
Although hearing about bugs seems a bit scary. Is HP interested in hearing feedback and fixing issues? I know they never once bothered to fix the major hardware flaws of the HP 49g/50g series. <_<
Indeed it really has potential IMHO. The bugs are not as bad as they used to be, but it's still common to read about users who got their calc to reboot or even freeze. I think the current team wants to fix the bugs, but the issue is that unlike the HP 50g where it was maintained by a team of about 50-400 staff members, the HP Prime is maintained by about 3-4 people who are in constant danger of losing their job through HP mass layoffs.
EDIT: That reminds me, if someone ever wants to make a game and doesn't mind minimal NES like graphics, he can easily use RANDOM functions and generate tiles of two colors with it to save space. :P
Quote from: DJ Omnimaga on February 09, 2015, 04:02:44 PM
Indeed it really has potential IMHO. The bugs are not as bad as they used to be, but it's still common to read about users who got their calc to reboot or even freeze. I think the current team wants to fix the bugs, but the issue is that unlike the HP 50g where it was maintained by a team of about 50-400 staff members, the HP Prime is maintained by about 3-4 people who are in constant danger of losing their job through HP mass layoffs.
Yikes. It would be a pretty smart move to lay off the only remaining OS developers. :P
To be fair, the HP 50g ROM had some updates for a while (I'm not even sure that the devs were still getting paid to do it), and I've heard that it's very difficult to modify due to so much being packed into the maximum available space, plus routines having to stay at fixed memory locations due to how RPL works. Supposedly, there's almost no room left for bug fixes (though I've also heard some argue there's room for optimization). However, my main gripe, I think, is with the ARM emulator or possibly the hardware design, which causes constant keystroke glitches, unreliable alarms when the calc is off (they're practically useless as a result), and even random freeze-ups.
What are the keystroke glitches? Do keys just stop working randomly or become scrambled like on the Nspire?
Wait keys get scrambled on the NSpire?? wow that's bad. TI at it again.
I forgot if that only happened with Ndless or not, but all keys would act as something else. For example 8 could have become Enter and Del might have become F
Quote from: DJ Omnimaga on February 11, 2015, 05:18:47 PM
What are the keystroke glitches? Do keys just stop working randomly or become scrambled like on the Nspire?
Often when you press a key (especially when it's right at the moment the busy annunciator goes off) it will be "ignored", only to get processed with the next key you press. Also, keys like arrows and backspace sometimes "stick" and continue moving the cursor or deleting everything you wrote after you press once, until you press another key (or hit the thing with a hammer). Same with shift keys and alpha sometimes, or they'll work inconsistently or the annunciator won't come on or off when it should. Also, the Try to Recover Memory? prompt for some reason sometimes refuses to accept any keys until you press a different key followed by the original one. (They actually put a note in a manual about that last one, rather than actually fixing it.)
Oh, that first thing is something the TI-84+CSE has issues with as well. In the slow program editor or home screen, when you type too fast some keystrokes get missed. I noticed that when a BASIC program is running, keys will not be memorized at all when the home screen is being updated too. In Mana Force, for example, the village used to be redrawn every frame, so when I ran the game on the CSE I was unable to move from house to house unless I started holding down an arrow key at the right moment. On the older calcs it's not a problem because of how fast the LCD is redrawn.
As for sticking keys I don't have this issue except on the HP Prime sometimes when I use the touchscreen to move the cursor somewhere in the program editor, but now it's no longer a real issue since they improved the editor speed considerably. I remember it would end up appearing somewhere when releasing the finger, only to appear one spot away a second later.
I guess back then HP was too lazy to fix HP 50g bugs. If only for the HP Prime they had as many people in charge of the OS as back then, this would probably become the perfect calc. But alas HP is in constant danger of going under since the last 8 years.
It would be nice to get a code blob with the so called "memory leaks" that you keep running into. As far as we can tell there isn't any relating to programming/graphic use. What does tend to happen though is that people keep making and creating full screen grobs which take 16bits per pixel internally and then *keeping* them around while making more. You just run out of memory quickly.
If I had an example though I could tell you if it is a problem on our side that needs fixing.
I will try to send you a copy of the program when I get some time. It could be something I am doing wrong but the lack of memory error messages and ability to store the amount of RAM and Flash in Ans to display it inside a program kinda makes things harder when debugging.
Welcome to the forums tim by the way. :)
Didn't know anyone wanted a command to get the memory/flash as reported by the OS.
Any problems with a command named MEMORY() which returns a list containing { RAM, STORAGE, [future stuff if ever any] }
It's not necessary, but I noticed that some 84+ game coders who used Asm libs liked to do that in their game or during debugging to inform the player that he might need to free up some memory and to help development. So I guess it wouldn't be a bad addition.