Do you have a Prime? I've been presuming you do and can look at it.
If not:
Almost every drawing command has two variations: a Cartesian and a pixel version. Pixel versions are suffixed with _P; for simplicity's sake they will be dropped as the positions do not matter here. GROBH(G) and GROBW(G) return the height and width of G. BLIT copies a GROB from one buffer to another, but with optional regions and optional alpha color: BLIT([trgtG],[dx1,dy1],[dx2,dy2],srcG,[sx1,sy1],[sx2,sy2],[c]). (Unless otherwise specified, optional GROBs default to G0.) INVERT inverts a region of a specified GROB in place: INVERT([G],[x1,y1],[x2,y2]). If the rotation was in-place, that would make calculations of position hard. I think Tim was thinking of something like that, but I'm not sure. Hence my suggestion of bitmap matrix transforms that can be sent to another GROB. There's a MSDN article on them in the context of DirectX that is pretty useful anywhere: DirectX Factor - 3D Transforms on 2D Bitmaps. It also discusses how 3D or 4D transforms can be used to do fanciness in a 2D or 3D plane if you're careful. It's awesome. It would actually be really cool if we could muck around with up to 4D matrix transforms and just specify optional values for z and w cross-sections, defaulting to 1 or 0, whichever would work better. (I'm getting sleepy and trusting my judgement here less.) Exemplī grātiā: MATTRANS([trgtG],[dx1,dy1],[dx2,dy2],srcG,[sx1,sy1],[sx2,sy2],matrix,[zPlane],[wPlane],[color]). We should be able to convert the 3D matrices from back to 2Ds with a z of 1 with some depth stuff, but the non-affines are worrying me, as they pull from values in the matrix. New idea: what if we could get and set a matrix of RGB values from and to a GROB region, such as GETMAT([G],[x1,y1],[x2,y2]) and SETMAT([G],[x1,y1],[x2,y2]) (with respective _P variants)? Then we could take a bitmap out, transform it, and...wait...array of 2D coordinates doesn't leave space for RGB values...how about returning 3D matrices with the z being the color?
/me refers back to the article
So, how about {GET,SET}MAT([G],[x1,y1],[x2,y2],[dimension]), where dimension defaults to 2 and the output/input is a q×(dimension+1) matrix (with the last part holding color) and q is the number of pixels. That should allow for the offloading of heavy transforms to the matrix functions and allow for easier custom transforms (like 3D→2D flattening).
So Tim, when you read this, something to consider. It would allow for some pretty cool stuff.

Yeah if you add a _P at the end of some drawing commands it uses pixels. I find those more handy, although cartesian can be handy as well if you manipulate window settings I guess and for 3D.


Basically, think of the HP PPL language as xLIBC-enhanced TI-BASIC on steroids. You can draw circles, rectangles (filled or not), sprites and transparent text with the color of your choice. However, it's several times faster and in addition to that, you can even scale up/down sprites/images, you have 10 graphical buffers for double, triple-buffering or more, plus you can also draw translucent polygons.

The following video showcases what you can achieve in HP PPL with no ASM/C nor any other hacks. For example,  the thing during the title that looks like Mode 7 is actually just displaying two images split into 120 chunks zoomed in at different levels. Something similar is being used for the Supersonic Ball logo:

Heya and welcome here. Thanks for the link by the way.


I was worried last week because people on the HP Museum acted like the firmware update is fake and will never happen when in fact it was just because they thought the announcment about it last month was official, only to be revealed as non-official by one of the team members. I didn't mind any delay, though, since it meant a more polished firmware and the last update from this Winter brought in a lot of improvements.

I'll definitively give this one a try soon

The only issue I noticed on the emulator personally (after finally installing it successfully by manually updating) is that my Tunnel game now crashes the emulator until I open the code then close it. Afterward it now gives Syntax error.

My apps are fine, though.


Also, another issue is that on both calcs and the emu the Send button is now missing, so I can no longer use the emulator to transfer files. I hate the connectivity kit for file transfer because it's so slow to detect anything at the start (about 60 minutes to detect 600 KB of programs)

Good to hear.

As for the missing Send button, I think HP just got rid of emulator transfer abilities, but I could be wrong. On the other hand, it seems that the new connectivity kit is much faster at detecting files now. It used to take 60 minutes and now it was done within less than one.