Preserving chip ram when loading lots of graphics

[earok]

Having a little bit of a problem with a project I've done, on some configurations with less than full Chip RAM it'll crash.

The main reason I'm not simply loading the frames when required is the delay to load each file is more than the length of time the frame is displayed on screen.

I'm loading each of the frames (it's like a slideshow) as BitMaps, I presume these are always loaded into Chip RAM so they can be instantly accessed by video memory?

Should I be loading these as shapes and blitting them to the bitmaps when required, or will that go straight to Chip RAM too?

How should I be managing this?

[Zetr0]

@earok

If I could be so bold as to suggest a form of RLE (Run-Length Encoding) - bitmaps being quite large are perfect candidates for RLE - have a read about the RLE Format

If BlitzBasic doesn't support RLE out of the box it is a very simple form of loss-less compression that you could build a RLE compressor / decompressor tools for your project in Blitz

Have a look at this youtube -
[ Show youtube player ]

RLE (Run Length Encoding) is widely used only a lot commercial games and software for the Amiga - it is a great way of storing data and arguably reducing its bandwidth in regards to copying data - this however Does put the onus of the operation on the CPU.

I hope that helps.

[earok]

Well, the thing is the graphics are RLE compressed to begin with (regular IFFs), but presumably they're uncompressed to be displayed on screen.. I guess I could simply try embedding them in the executable, out of the box Blitz supports decompressing IFFs that are in memory

[Daedalus]

Yep, if you include them in your executable they will be in fast RAM with the rest of the code until decoded, then they'll be in chip RAM. Don't forget to free the memory from previous frames first!

Loading any graphics with Blitz will always go directly into chip RAM, be it shapes, bitmaps, sprites or whatever. However, if the full frame isn't changing, some memory can be saved by blitting a shape over the region that changed. But really, there's not much that can be done with Blitz's built-in commands in that way.

You could also manually copy frames in and out of chip RAM from fast RAM if you wanted - decode the shape, copy it to a fast RAM location, repeat. Then copy the required frame back to chip RAM when it's needed. That way you'll only need enough chip RAM for two frames - the displayed one and the next one.

[earok]

Thanks mate that explains it well

[Cylon]

That was for starters, of course. Later on you will realise not to use IFF at all for image loading and instead use plain data (in whatever 'shape') and load/decode it to any type of memory.

Copy img data back and forth is costly.

And donot believe

But really, there's not much that can be done with Blitz's built-in commands in that way.

Just don't.

Oh, and don't include any big chip data into your exe, because you have to copy it back to chip memory anyway (on FastRAM machines) during execution and therefore waste *twice* as much RAM on the way, as you cannot free the occupied memory parts taken by your executable.

[Daedalus]

Is there a way to use the built-in graphics loading commands to load graphics into fast RAM?

[Zetr0]

@Thread,

This is one area I found Blitz to be quite weak - Blitting Data from FAST to CHIP - If your running a 40Mhz 030 or higher its quicker for a F2C CPU implementation than the use of the Blitter.

I was quite lucky in some respects learning C/C++ way before Blitz Basic - from this I have a couple of hints.

If you are using the CPU as opposed to the BLITTER ensure the Bitmap Mask(s) are stored in FAST. You could write a function that takes an RLE graphic file stored in FAST RAM and use the CPU to read both the graphic and then mask to then BLIT to a Chip RAM Window or display array.

A rule of thumb is to only allocate twice the CHIP RAM you need for a SCREEN - the rest you can buffer from FAST RAM - this gives you the option of Double Buffering - which is a must if you want smooth scrolling.

[idrougge]

Originally Posted by Daedalus

Is there a way to use the built-in graphics loading commands to load graphics into fast RAM?

You could incbin the file(s), allocate enough chip RAM, use CludgeBitmap to make a bitmap in chip RAM and _CopyMem it there.

[Daedalus]

Yep, that's pretty much the approach I was thinking of. What I was trying to point out (though I probably needed to be clearer since I think I was misunderstood) is that you can't do that with the standard Blitz object commands for handling graphics, sounds, palettes and what not. They're all hard-coded to work in chip RAM.

[Cylon]

Originally Posted by Daedalus

Yep, that's pretty much the approach I was thinking of. What I was trying to point out (though I probably needed to be clearer since I think I was misunderstood) is that you can't do that with the standard Blitz object commands for handling graphics, sounds, palettes and what not. They're all hard-coded to work in chip RAM.

Yes, you wrote "built-in commands", but there are very few cmds actually built'd in. The mentioned ones are not of them. That's why i put the starter p.o.v. into this discussion.
All bmap blitting is done with cmds from an 'external' blitzlib. You can update it, you can replace it, you even can add a new lib only dedicated to cpublit/cpudraw and what not.
I've got my own cpu-plotting/line drawing on bplane level in an own blitzlib, so can you.

First of all:
Discard IFF-handling. You can kick out the need for iffio.lib and therefore iffparse.library in the Libs: folder - you might have no right to distribute that anyway?
Then:
Use shapes or (compressed) raw data for the graphics, use tables for the colour setup of the palettes.
Further:
Load those data files to spare FastRAM in a smart way, copy (or cludge) to ChipRAM only when needed.

Do not IncBin large gfx or sound to the executable, unless you are sure your target will always be Chip only. Then (and only in this crazy case) you can save memory and overhead in transfering data, because you can point to this data to avoid loading.

[Daedalus]

Ah, fair point. I'm using AmiBlitz 3 so long I think of anything that's in the original Acid Libs as "built in", and the AmiBlitz includes and extra Userlibs as the additional functions. I should really know them better than that, I've recently installed every different major version of Blitz in order to document the differences

[idrougge]

Well, you can use the Mildred library. It's a very thorough Blitz library for c2p and storing graphics in fast RAM. http://www.david-mcminn.co.uk/blitz-...hives/mildred/

[earok]

How would one load graphics (bitmaps, shapes or anything) into FastRAM without incbin'ing?

The only thing that's really stopping me from incbin'ing everything is that the executable has both an AGA and an ECS mode (eg I don't want to load all the graphics for both versions into memory).

I suppose it is an option to create entirely separate executables and use a script to boot the correct executable based on whether or not AGA is detected.

[clenched]

Originally Posted by earok

How would one load graphics (bitmaps, shapes or anything) into FastRAM without incbin'ing?

I would use LoadBank with the public ram option. Fast ram is the first choice then. This program loads four pictures from DPaint 5. The doggie picture is four planes instead of five. By commenting out the cls line, one leftover plane of the Earth picture can be seen. This is just to prove the same chip ram is being recycled.

LoadBank 0,"seascape.lores",1
LoadBank 1,"venus.lores",1
LoadBank 2,"worldmap.lores",1
LoadBank 3,"doggiebackground.lores",1
;NPrint Hex$(Bank(0)):Stop ;check really fast ram
BitMap 0,320,200,5
InitPalette 0,32
InitCopList 0,44,200,$5,8,32,0
DisplayBitMap 0,0
BLITZ
CreateDisplay 0

For j=0 To 3
Cls 0
DecodeILBM 0,Bank(j)
DecodePalette 0,Bank(j)
DisplayPalette 0,0
VWait 50
Next j
MouseWait
End

[earok]

Thanks mate, I think that's exactly what I need

[clenched]

I'm dissatisfied with the way this is working on an A500 setup. DecodePalette hangs the program. Paste this part over the bottom half of the original. It just copies the colors from selected IFF into the existing palette. Also this is done ahead of DecodeILBM so there won't be an abrupt flash of color. With this I was able to display all four pictures with A500 KS2 and A1200 KS3.

For j=0 To 3
Cls 0
GetReg a0,Bank(j)+48              ;palette offset in IFF
GetReg a1,Peek.l(Addr Palette(0)) ;existing palette structure
  MOVE.w (a1)+,d0                 ;# colors
  MULU.w  #3,d0
l1:
  MOVE.l #0,(a1)+
  MOVE.b (a0)+,-2(a1)             ;overwrite existing palette
  SUBQ.w #1,d0
  BNE l1
DisplayPalette 0,0                ;refresh display
DecodeILBM 0,Bank(j)
VWait 50
Next j
MouseWait
End

[earok]

My assembly is weak but I think I follow it. Would this work the same with AGA palettes, or require some adjustment?

[clenched]

I don't know about AGA but DecodePalette is still there. Also this simple program will only display OCS pictures of the same size and resolution without adjusting the bitmap and copperlist accordingly. These are the BASIC lines tested first. It was way too slow suit me on the A500.

For i=0 To 31
r=(Peek.b(Bank(j)+48+i*3)) LSR 4 AND 15
g=(Peek.b(Bank(j)+48+i*3+1))LSR 4 AND 15
b=(Peek.b(Bank(j)+48+i*3+2))LSR 4 AND 15
PalRGB 0,i,r,g,b
Next i

EDIT: This line didn't make it to the first listing when pasted.
InitPalette 0,32
So that has been attended to.

[clenched]

Good news. First make sure the same Blitz is in use. Mine says Blitz Basic 2 Version 2.1 SuperTED v2.52.

Look in drawer Developers/userlibsrc for RIPackLib.bb source code.
These commands will be used instead of DecodeILBM & DecodePalette.

!name {"UnpackIFF","(sourceaddr,bitmap#[,numlines,xy_offset])"}
!name {"ILBMPalette","(sourceaddr,palette#)"}

This file needs to be recompiled to work properly on BB2 so load it.
Check compiler options so no boxes are highlighted and click create executable. Move to directory Blitzlibs/otherlibs and select file RIPackLib.obj size 2764 bytes. Overwrite that file. In my case the new file is 2612 bytes.

Finally run the Blitzlibs:makedeflibs program to incorporate the changes. Shut down, restart Blitz and try to compile test programs on the ADF.

Contents of ADF:
ri - a little slide show of 5 DPaint 5 pictures.
riaga - stress test 320x1600x7 planes (use mouse / tiles ripped from Moon Child game)
txt - ASCII listing of above
the rest - IFFs

I went straight down the line of every available wedge Amiga model quickstart and picked the first fast or alias configuration and it worked fine every time.