CodeWalrus

u/Dream of Omnimaga May 18, 2015, 04:46:52 PM

In the past, we just loaded our graphics directly with DIMGROB and the string of data was massive. However, I believe that this might have been faster overall and might explain the lag that I got in one of my programs. I will definitively have to experiement with the tilemapper I made once to see if displaying graphics froma GROB is much faster than from an ICON.

u/alexgt May 18, 2015, 05:22:00 PM

Quote from: timwessman on May 18, 2015, 02:47:03 PM
Quote from: Cumred_Snektron on May 18, 2015, 06:03:39 AM
Whats a GROB btw?

It's been the HP parlance for GRaphic OBject since 1989 or so.

As for the problem for which I was summoned - there are a couple of questions to ask here.

Are you really meaning to create a 1600x800 <unit> sized GROB?

If so, are you remembering that the <unit> size comes from the Cartesian grid of the current application? So if the function app is running and the user has zoomed in by 2x on the graph, your GROB size just doubled which would already cause your memory to run out. My recommendation would be to always use the _P options to specify an exact size else you are left at the mercy of what the user has done to the Cartesian grid. If you really want to use the cartesian grid, you'd better make certain you set the values to the desired setting by using the Xmin/Xmax/Ymin/Ymax. However, those only exists for about half of the apps that have graphing. Better to just pick your correct pixel size.

Are you cleaning up after the exit of the game? By this, I'd recommend clearing out your large graphics by setting them to 0 or 1 pixel in size. Else that memory will stay in use until the user either resets, or stores something else in there.

With the new firmware, I'd recommend switching to an application. That will give you access to permanent variables that aren't lost on editing, as well as files and an icon for your program. My recommendation would be:

1. Save a copy of the Quad Explorer app (this will be very tiny).
2. Make your START routine be to launch the game, as well as the Plot, Symb and Num routines.
3. In the code itself, get rid of all the uses of ICON. On the PC, you will see that the applications are now folders of the form "<name>.hpappdir". Put all your graphic assets into that directory as png files (.png on the name is not necessary for use/loading - we check the header to determine type) and they will be sent along with it when sending from the connkit.
4. Give a 38x38pix item a name of "icon.png". That will be what is used for your application icon.
5. When you want to load your png files, use G2:=AFiles("filename") or similar. I'd avoid using the AFiles(1) as that file order could change! It depends on what the underlying file system does with the files in how it lists them. Then once you have G2, you can use that to create your larger GROB. Going directly from the png decode to the blit will definitely increase load time.
6. If you have data you want to save, AFiles("name"):=G1 will store it out. You might even be able to store the PNG as built to disk. Not certain of that though due to the large sizes that appear to be involved.
7. If you have data you want saved (scores, map info, etc), do a AVars("name"):=<list_or_whatever>. Note that the primary difference between using AFiles or AVars is that AVars will allow you to use the object directly as a variable (tying MyVar for example) while AFiles will not. You have to load to a variable from AFiles before use. AVars will consume RAM when the app is loaded. AFiles will not until they are recalled to a variable.

8. To distribute your new application, just package the "name.hpappdir" in a zip file! People just need to drop that zip on the calc in the connkit and it will send the application. No messing with pasting of source. This is the strucutre we like to use for distributing HP developed apps for teacher use for example:

<ZIP>
|-- appname.hpappdir
| |-- stuff
|-- readme.txt
|--help.pdf
\--last file

Provided your stuff is not an hp object type (.txt, .pdf, etc) it will not be sent. Anything in the hpappdir WILL be sent as a file, but it will not recursively add things (aka, no nesting of directories in there).

A post over on the HP museum saying the calcuator was out of memory or something if you feel that was the case and have nothing else to discuss about it.

I do use the _P system that was just a mistake in the example code but it works fine now. I will definitely switch it to an app when I have time.

u/timwessman May 18, 2015, 05:39:08 PM

Quote from: DJ Omnimaga on May 18, 2015, 04:39:46 PM
Ooh that is nifty. I didn't know we could now have applications with custom icons and files this way. I will definitively have to keep this in mind when I make larger games. Just a question, though: Are application icons and files compressed like PNGs? Because the other HP Prime format seemed extremely large and I would rather have my programs not be 400 KB large again like in 2013.

Any GROB object saved to disk is converted to a PNG. You can also load directly from a PNG file to a GROB object (it uses the headers not extension to determine if it is a PNG - so no need to restrict your filename to .png extension if desired). Note that the calculator screen is 16 bits with 1 bit for transparency on/off. You do *not* have ALPHA support, but you *do* have transparency support. So a png with a completely transparent region will have a transparent region when loaded (think sprites).

Quote
Also I didn't know that on program exit the GROB content was not cleared automatically. That might explain why some games behaved strangely after running several other ones.

Yes. There would be no way to know if the user wanted G1 or similar to be used elsewhere and hence no way to "clean" the memory up.

The act of using an ICON keyword would *also* make an object in memory that would never be freed. The ICON keyword was meant for objects where absolute speed was required and is essentially a hex representation of a bitmap. Not small at all, but absolutely fast. I would recommend not using ICON for anything however unless you really feel you have to do so. The speed difference between decoding a PNG to a G2, then using G2 for your tile copy multiple times will be essentially non-existent. Now if you read and decoded the PNG each time that would be another thing entirely...

See the screenshot where I created an icon.png with a completely transparent region. You'll note the icon has transparency around the edge of the silly little walrus...

Last Edit: May 18, 2015, 05:48:49 PM by timwessman

u/Snektron May 18, 2015, 06:32:48 PM

A bit off topic but: What's Ebola2 for kind of library?

u/timwessman May 18, 2015, 06:37:29 PM

Quote from: Cumred_Snektron on May 18, 2015, 06:32:48 PM
A bit off topic but: What's Ebola2 for kind of library?

It comes from a statistics activity being prepared using data from the recent outbreaks to discuss logistic fits. Just happened to be the one I clicked on when adding the icon...

u/Dream of Omnimaga May 18, 2015, 07:09:14 PM

Quote from: timwessman on May 18, 2015, 05:39:08 PM
Quote from: DJ Omnimaga on May 18, 2015, 04:39:46 PM
Ooh that is nifty. I didn't know we could now have applications with custom icons and files this way. I will definitively have to keep this in mind when I make larger games. Just a question, though: Are application icons and files compressed like PNGs? Because the other HP Prime format seemed extremely large and I would rather have my programs not be 400 KB large again like in 2013.

Any GROB object saved to disk is converted to a PNG. You can also load directly from a PNG file to a GROB object (it uses the headers not extension to determine if it is a PNG - so no need to restrict your filename to .png extension if desired). Note that the calculator screen is 16 bits with 1 bit for transparency on/off. You do *not* have ALPHA support, but you *do* have transparency support. So a png with a completely transparent region will have a transparent region when loaded (think sprites).

Quote
Also I didn't know that on program exit the GROB content was not cleared automatically. That might explain why some games behaved strangely after running several other ones.

Yes. There would be no way to know if the user wanted G1 or similar to be used elsewhere and hence no way to "clean" the memory up.

The act of using an ICON keyword would *also* make an object in memory that would never be freed. The ICON keyword was meant for objects where absolute speed was required and is essentially a hex representation of a bitmap. Not small at all, but absolutely fast. I would recommend not using ICON for anything however unless you really feel you have to do so. The speed difference between decoding a PNG to a G2, then using G2 for your tile copy multiple times will be essentially non-existent. Now if you read and decoded the PNG each time that would be another thing entirely...

See the screenshot where I created an icon.png with a completely transparent region. You'll note the icon has transparency around the edge of the silly little walrus...

Nice. Will DIMGROBHelper work for app icons? I do not have any image editing software that can produce 32768 color PNGs with transparency.

u/alexgt May 18, 2015, 07:28:43 PM

I thought that ICONs were smaller than GROBs?

u/timwessman May 18, 2015, 07:51:57 PM

Quote from: DJ Omnimaga on May 18, 2015, 07:09:14 PM
I do not have any image editing software that can produce 32768 color PNGs with transparency.

You don't need one. It is a fully compliant png implementation. Conversion to specific colors happens internally on load. Do you have something that will edit and save a png image? Now if you really want to have complete control down to exact colors you'll need an editor or converter that handles it at that color depth, but I seriously doubt that is needed except in possibly the most exacting uses.

Quote from: alexgt on May 18, 2015, 07:28:43 PM
I thought that ICONs were smaller than GROBs?

Exactly the opposite. ICON represents the GROB, but using a plain text hex format - two 16 bit characters to represent the single 16 bit pixel. When parsed, it creates an internal GROB from the text. You thus have used 3x the space needed then just for the GROB alone.

u/Dream of Omnimaga May 18, 2015, 07:59:32 PM

I have Photofiltre Studio, which saves as PNG but only 8 and 24 bits. Would non-alpha transparency be preserved upon importing to the connectivity kit?

u/alexgt May 18, 2015, 08:13:12 PM

Then MinePrime could be 3x smaller

(I use the ICON format for the texture pic). Is there any way to name a GROB? Can you just do:

Code Select


LOCAL ABC;
DIMGROB_P(ABC,320,240,data);

to make a GROB with its own name?

Also for S.I.F.S. is there any way to call a program in a program because I want it to be a shell kind of.

Thanks for all the help Tim

u/bb010g May 18, 2015, 08:45:53 PM

Quote from: DJ Omnimaga on May 18, 2015, 07:59:32 PM
I have Photofiltre Studio, which saves as PNG but only 8 and 24 bits. Would non-alpha transparency be preserved upon importing to the connectivity kit?

The GIMP or Krita should work fine.

u/alexgt May 18, 2015, 11:32:14 PM

Quote from: timwessman on May 18, 2015, 07:51:57 PM
Exactly the opposite. ICON represents the GROB, but using a plain text hex format - two 16 bit characters to represent the single 16 bit pixel. When parsed, it creates an internal GROB from the text. You thus have used 3x the space needed then just for the GROB alone.

I just made the DIMGROB_P() data and it was 747Kb in size compared to 356Kb for the ICON data? what did I do wrong?

u/Dream of Omnimaga May 18, 2015, 11:41:27 PM

I think I'll stick to regular programs if the program size is gonna be this much larger, especially with complex images that lacks compression. At least with ICON format, when the program is not running it doesn't take that space once I cleared it out.

u/alexgt May 18, 2015, 11:50:11 PM

No I wasn't saying that the App size was larger. I was actually in a regular program what I did was use DIMGROB helper to make a DIMGROB() command. I am sure that Apps are ok for anything. Also they have a nice GUI in the apps menu

.

u/Dream of Omnimaga May 19, 2015, 01:08:24 AM

Oh I see lol. That said, when we compare GROB format with ICON, the difference isn't always 3 times larger. Sometimes it's even worse, because ICON uses some sort of compression for simple images. For example, if you converted a 1920x1080 picture containing just white into ICON format, then the resulting code is about 3 KB large. However, the GROB version is 11.5 MB large!!