Asm: 4 bitplanes starfield (68020+)

[alkis]

Hello ppl,

After going through the excellent video tutorials of Photon, and reading a couple of threads (on plotting dots and rand) in here, this is what I came up with.

Tested that assembles in vasm and asmone. Needs 68020

Left mouse button exits, right mouse button enables color switching of $dff180 so you can see raster timing.

[modrobert]

I like this starfield, nice effect, thanks for sharing.

There seems to be something wrong with the code initialization (register not cleared?) because sometimes I get coloured stars on my A1200 (not grey shades, still the bug looks great, hehe), other times there is a vertical orange bar (roughly 50 pixels wide) from top to bottom of the screen, most of the times it works as intended.

Compiled with: vasm star4bp.s -o star4bp -m68020 -Fhunkexe


BTW:

I remember trying something similar when learning 68k assembler long ago, but the routine was much simpler, didn't look this good (not using several bitplanes).

[Leffmann]

Try writing $C40 to BPLCON3, and $11 to BPLCON4. This will set the AGA palette- and color table features to OCS compatible settings.

[modrobert]

Leffmann,

That worked, thanks.

I added theese two lines during init (right before the create palette comment).

move.w #$C40,$dff106
move.w #$11,$dff10c

[alkis]

Thanks for the comments and the fix! (applied)

Here is a new version with double buffering (less stars flickering)

Waiting for $2a on $dff006 wasn't very double-buffering friendly so I switched to waiting for vertical blank. Added some ugly text routine (on right mouse button displays raster position when the frame loop reaches it's end).

But I am thinking that to have a non-glitch starfield you need tripple-buffering, right?
Cause, ok, I am clearing the backbuffer, I am writting to active screen...but I guess I miss the stars with y (screen) pos less than the current raster pos.

Cheers,
/Alex

[alkis]

On a sidenote, sublime editor is quite nice (http://www.sublimetext.com/)

If you go to Tools/Build System/New Build System and edit it to:
"cmd": ["vasmm68k_mot","-Fhunkexe","-m68020","$file"]

and then save it as vasm.

You can ctrl-b to build your source code.

Also, if you install the M68ksyntax highlighting, it gets even nicer.

[modrobert]

Any Amiga version of the sublime editor (can't find the source code either)?

I currently use JanoEditor on the A1200, simple but good (nice with the tab feature, typing 'run jed foo.txt' in a shell just opens a new tab if the editor is already running). Was going for 'vim' first, which is my choice in Linux, but the port just got too bloated, sluggish and anti Amiga somehow.

[britelite]

Originally Posted by alkis

But I am thinking that to have a non-glitch starfield you need tripple-buffering, right?
Cause, ok, I am clearing the backbuffer, I am writting to active screen...but I guess I miss the stars with y (screen) pos less than the current raster pos.

No, double buffering should be just fine. Haven't looked at your source yet, but you need to make sure the active screen is being shown before you start modifying the backbuffer.

Basically: wait for VBL - change screenpointers - do your magic on backbuffer

[alkis]

@modrobert
No amiga version of sublime. I should have specified that is for cross-developing, sorry. (I am using it on linux) Also, it’s closed source and quite expensive. Still, the free download is fully functional.

@britelite
The flow I have is:
- Wait for VBL
- Change the screenpointers
- Start blitter clearing the screen that is NOT showing
- Calculate new position of stars and draw them at the screen that IS showing
If I (or the emulator) haven’t messed up the timing, I measured the clearing of 320x256x4 with the blitter as needing almost a whole frame (minus 10-20 raster lines). So, if by “do your magic on backbuffer” you mean draw stars in the backbuffer, then I don’t think I have the time for that. (would have to waitblit before drawing any stars too)

[hooverphonique]

the number of buffers doesn't necessarily matter.. Heck, you can use single buffer if you stay ahead of the beam at all times ;-)

the static vertical bar is probably due to sprites not being properly reset..

[phx]

A size optimization hint:
Put the screen buffer into a BSS section. This will shrink the size of your executable from 138K to 1.5K.

Another possibility, when running under OS2+, would be to use the -databss option. It will remove all zero data from the end of a section.

[alkis]

@hooverphonique
That would be very difficult to achieve with random y-coordinates from stars :-)

@phx
thanks, patch applied ;-) I went with the BSS section solution, but I got to 7640 bytes and not to 1.5k with vasm (on linux, if that matters...7056 with asmone, 6932 on vasm's executable if I apply m68k-amigaos-strip on it)

[phx]

Originally Posted by alkis

thanks, patch applied ;-) I went with the BSS section solution, but I got to 7640 bytes and not to 1.5k with vasm

I made my test with -databss. That's because also the code section has many KBytes of zero data at its end:

        dcb.b   NSTARS*starsize

You may want to move it into a BSS section as well.

[alkis]

@phx
Yeap. Went to 1568 bytes :-)
vasmm68k_mot -m68020 -Fhunk -o star4db.o star4db.s
vlink -bamigahunk -o star4db -s star4db.o
ls -l star4db
-rwxr-xr-x 1 alex alex 1568 Aug 29 22:34 star4db

[britelite]

Originally Posted by alkis

@modrobert
- Calculate new position of stars and draw them at the screen that IS showing

Yes, your problem is right here. All the drawing should be done on the buffer that is not showing

(Edit) Drawing everything in the backbuffer is the whole point of double buffering, and it doesn't slow down anything (unless there's something wrong with your code)

[alkis]

The original code (first post), clears star, calculates new position, draws star in new position. All that in a single screen. (could do about 900 stars in one frame on emulated A1200)

The second version, eliminates clearing each individual star (and all the housekeeping needed for that) by clearing the whole screen with the blitter, calculates new position, draws star in new position. (this is an overall gain as it can go up to 1600 stars/frame on emulated A1200)

The thing is that I can’t draw stars in the backbuffer on the second version, cause backbuffer is being cleared by the blitter. If I waitblit, I bet it would be an overall loss and I’d be able to do something like 100-200 stars/frame.

That’s why I wondered if in order to keep the gain of using the blitter in parallel, you actually need triple buffering.
- One screen, blitter clears it
- Second screen, draw stars in it
- Third screen, display it

[britelite]

Originally Posted by alkis

The thing is that I can’t draw stars in the backbuffer on the second version, cause backbuffer is being cleared by the blitter. If I waitblit, I bet it would be an overall loss and I’d be able to do something like 100-200 stars/frame.

Ok, I missed the part about clearing the screen with the blitter.

That’s why I wondered if in order to keep the gain of using the blitter in parallel, you actually need triple buffering.
- One screen, blitter clears it
- Second screen, draw stars in it
- Third screen, display it

Yeah, this should work fine.

[hooverphonique]

Originally Posted by alkis

@hooverphonique
That would be very difficult to achieve with random y-coordinates from stars :-)

[alkis]

Ok, just for completeness shake, here is the same thing with tripple buffering.

At least in my emulated A1200, fixes disappearing stars on the upper half of screen (as it should).

That's it. No more starfields, I promise :-)

[mc6809e]

Originally Posted by alkis

That’s why I wondered if in order to keep the gain of using the blitter in parallel, you actually need triple buffering.
- One screen, blitter clears it
- Second screen, draw stars in it
- Third screen, display it

Definitely worth doing.

This trick also works really well when using the CPU to clear a buffer while the blitter is line drawing or area filling in another.