Global variables and HP-GCC
in [HP48]
|
Prev: New HP 50G Owner
Next: EMU48
From: am on 1 Sep 2006 15:16 > My program already includes a very primitive editor (well, you can move > with the cursor and toggle the pixels), and I had further plans to have a > pattern library (to be able to insert some simple patterns like gliders or > *WSSs), copy and paste functionality, to have a simple filer to load pattern > definitions from SD card etc. - but it's unlikely that I'll ever get to > implementing these features. Well... that sounds like a lot of features. And very cool ideas! I think I'll soon implement a toggle-editor like yours. It would be nice to load a grob from stack... maybe with such a functionality the user could simply use a directory of grobs as pattern library. > > On hpcalc.org there's a nice program > > that does this, written in Saturn assembly, but it seems to be not > > fully compatible with the bigger screen of the 49g+ (and, though very > > fast, it is still slower than what hpgcc achieves even in slow mode). > > How fast is your program? I couldn't get out more than 5 fps from my > (admittedly not optimal) algorithm. After several tries, at the moment I can get 8-10 fps in slow mode and 20+ fps at full speed. ---am
From: Jean-Yves Avenard on 1 Sep 2006 21:04 am wrote: > Thanks for your answers. > After some crashes, it seems I've managed to write some working code. > Check the following example program, it draws a nice cubic on a > patterned background. You need to make sure PICT exists before you start your program. By default PICT will be an empty graphic. To create PICT you can do something like { #0 #0 } PVIEW which will automatically create PICT if it doesn't. JY
From: am on 2 Sep 2006 10:00 Jean-Yves Avenard wrote: > You need to make sure PICT exists before you start your program. > By default PICT will be an empty graphic. > To create PICT you can do something like { #0 #0 } PVIEW which will > automatically create PICT if it doesn't. You're right, initialization might be needed. But it would be more consistent writing it in C. Does anyone know how to do it? Evidently just writing a grob header at GDISP's address is not the right way, I guess some allocation in Saturn memory is needed. I have two other questions: does the address at GDISP ever change, and why? (Do I have to be worried about it?) And, if the grob prologue is #02B1Eh, why does my PICT start with #F2B1Eh ? Thanks!
From: Claudio Lapilli on 2 Sep 2006 11:06 am wrote: > Do you guys at hpgcc think that functions to load/manipulate grobs > should be included in hpgcc? As you can see from their importance in > the game of life program, such functions could prove to be very useful > to provide graphic input to a program. Moreover, grobs can be sent to > infrared printers. We have HPG, a full featured graphics library that can work with monochrome, 4-grays or 16-grays bitmaps. You can write a much better (faster) program if you use our library instead of working with grobs directly. A monochrome grob_to_hpgbitmap() converter function (and viceversa) should be very simple to write. I will probably include in hpgcc a very primitive sat_creategrob() function to create grob objects on the stack (don't expect anything before Jan 2007, though). Keep in mind that programs requiring graphic input are relatively rare. Good luck w/your program, you should be able to achieve much more than just 8 fps in slow mode, the ARM processor can do better than that! Claudio
From: am on 2 Sep 2006 14:13
Claudio Lapilli wrote: > We have HPG, a full featured graphics library that can work with > monochrome, 4-grays or 16-grays bitmaps. You can write a much better > (faster) program if you use our library instead of working with grobs > directly. > [...] > Good luck w/your program, you should be able to achieve much more than > just 8 fps in slow mode, the ARM processor can do better than that! Well, I must confess that my first attempt used hpg_t* images, but I couldn't get more than 3 fps (in slow mode). Switching to a simple array for intermediate images and using HPG only for drawing to the screen, the speed becomes 8-10 fps (in slow mode). I guess this is because Life has to use a function call to set each and every pixel, and for each of them HPG does more than a function call and has to calculate offset (hpg_t images may have generic size, so I guess this is relatively slow). Am I missing something? Any tip? Thanks ---am |