Software sprites?

[nippur72]

I just finished reading the docs, very nice job!

Is it possible for you to release a compiled version with absolute addresses and explicit symbols? I have several issues porting it to DASM, so it would be nice if you could provide a file that I can bulk include in my dasm source.

All I need is a file like this:

; sss symbols
SSSINIT = $<....>
SSSIRQ = $<....>

.ORG <sss start address, you choose a convenient address>
.BYTE <SSS memory dump here>


Before you ask, I tried to convert myself to ca65 but I can't get used to it.

[rhurst]

That's a good idea, and I don't see why that cannot be done.

[rhurst]

Ok, I added a new "fixed" folder with two pre-made binaries, but both can be easily tailored for the type of binary needed and/or starting address. It can be downloaded here.

The first binary is a self-loading PRG that will go into VIC with a 3k RAM expander ($0400 - $0FFF), i.e., LOAD "FIXED-0400.PRG",8,1

The second binary has no address header, so it must be included (.incbin) with your assembler project. It loads at the top-end of an 8K memory expander, starting at $3500 - $3FDA.

There are ca65 generated MAP and SYMBOL files, but you will have to translate them into dasm format yourself. From what you described, that should not be too difficult to do. Good luck!

[nippur72]

I just finished to study the "primer" example with the aid of printed docs, again, a very nice job. I haven't written any code yet, I am just getting acquainted to the library and the way it works.

Some questions/random thoughts:

- SPRITECOL has a bit for hires/multicolor sprites, is multicolor really supported? (I ask because I haven't seen that feature in the demos).

- I don't understand how a 3x3 chars sprite is 16x16 pixels large (as in SPRITEDEF = %00001111). This is a bit confusing, is maximum size 2x2 or 3x3 ?

- How to detect sprite collisions? is there a bit returned somewhere, or collision must be implied from coordinates? Looking at quickman it seems to me that collision is coordinates-based, is that correct?

- What is color sprite priority, that is, if many sprites overlap, whose sprite color is actually displayed in the overalapping cell?

- a suggestion: is it possible to render sprites in XOR style (a la Shamus)? perhaps it could be done with self-modifying code (EOR in place of OR istruction)?

[rhurst]

is multicolor really supported?

if (Really == bit-masking) return FALSE;
If you keep the sprites isolated, as I do in the Quikman and Omega Fury title screens, you can use a multi-color value in SPRITECOL to paint the sprite with. I do not manipulate nibbles, only bits.

I don't understand how a 3x3 chars sprite is 16x16 pixels large (as in SPRITEDEF = %00001111). This is a bit confusing, is maximum size 2x2 or 3x3 ?

You define/store your sprite image in 2x2 format, and point to it with SSSANIM. If the SPRITEDEF bits are on (in your example) to allow for floating X/Y, then the storage for the rendering and display matrices (SPRITEBUF, SPRITEC1, SPRITEC2) are 3x3, to allow for the pixels to be shifted whole inside. If any of those bits are off, the image is truncated.

How to detect sprite collisions? is there a bit returned somewhere, or collision must be implied from coordinates? Looking at quickman it seems to me that collision is coordinates-based, is that correct?

That is correct. I do not do any sprite masking; it's extra operations within the rendering loop I thought best to avoid. Yes, I simply do coordinate collision (aka, box boundary checking) to determine the degree of the "hit". Quikman allows for 5-pixel overlap with a monster. Omega Fury's bolts calculate from its center dot to within the SPRITEX/SPRITEY + 8. Not entirely accurate, but they are lightweight calculations and effective.

SSSPEEK and SSSPEEKS allow to look at background and foreground character cell for sprite checking (dots, power pills, fruit, and Thargoid mines come to mind).

What is color sprite priority, that is, if many sprites overlap, whose sprite color is actually displayed in the overalapping cell?

Active / visible sprites get rendered from lowest numbered (0) to highest numbered (SPRITEMAX-1), whereas the higher numbered sprites are "stacked" if they should overlap. So that's your color priority.

a suggestion: is it possible to render sprites in XOR style (a la Shamus)? perhaps it could be done with self-modifying code (EOR in place of OR istruction)?

I don't see why not, but then again, I do not see why you would want to. I am a fan of Shamus and I understand why the author implemented that rendering style. If a VIC game has the potential for a lot of sprite overlap, you have to consider making all those images monochrome. I am not a fan of VIC multi-color -- beyond static images or isolated animations. VIC-II addressed all those weaknesses VIC has, plus you get 8 hardware sprites with all the features you have listed here.

When I move on to TED (C16 and Plus/4) next for some fun retro-gaming programming, I was planning on tinkering with some of what you mention here. Those machines are a little faster and offer much better video, which makes animated multi-color features desirable. And that work will port nicely to C128, although it will suffer a significant drop in palette choices -- but it will run great alongside hardware sprites. You can see why real arcade action games are possible with VIC-II -- and less challenging to program, too.

You make a great example with Shamus (and Omega Race) style of rendering. The monochrome look works (and plays nicely on B&W TV screens of the day) and can be technically more accurate for collision (and sometimes too accurate as horizontal laser shots squeeze between Shamus head and hat) -- and monochrome comes without the extra chunky-sized pixels over what already exists. But I have found that VIC "hires" graphics with the color clashing/bleeding that occurs between overlapped character cells manageable. In fact, explosions in Omega Fury make for great coloring as you easily change red-to-yellow-to-red per explosion image frame -- and that color overlap translates on the portion of the ships or shields' character cell it touches, making for a nice effect. You can do the same for multi-color rendering, but the images are fatter looking and slower.

When you look at what you have to work with here in VIC and it sometimes translates to that little "why bother?" feeling, I keep reminding myself that the VIC fullscreen resolution is about the size of a nice SVG icon on my desktop. That's my challenge, and that's why it is fun (for me).

I see my Quikman running on Mega-Cart, and it excites me to see a fair representation of the real arcade game running on such modest hardware -- 8-colors, less resolution, no multi-color, but its handling is smooth and there are no quarters required -- something I always dreamed it could do, but I couldn't quite get there given the stated reasons. And that effort is now pushing me to see if I can squeeze out a little bit more in Omega Fury. I rather do this puzzle on my train commutes than Sudoku -- you should see the curious looks I get from other passengers spying my laptop screen!

[nippur72]

thank you for the detailed reply, it cleared all my doubts!

I think I'll really miss the pixel-based collision check, but I fully understand the reason why you have omitted it. When I added the pixel collision in PONG, the sprite rendering routine became much slower, having to store the partial result of the "OR" operation between sprite and background (but I kept it as I had only one sprite, the ball).

[nippur72]

I'm having a problem with the "fixed" binaries.

I have written a small test program that is something like this

Code: Select all

   ORG $1201
   <basic stub>SYS MAIN

MAIN:
   LDA #$06	
   STA COLORCODE
   JSR SSSINIT
   RTS

   ORG $3500
   INCBIN "fixed-3500.prg"

The SSS library is correctly located at $3500, with the routine SSSINIT correctly placed at $381f (inspected with monitor).

But if I execute the program, it does some filling and then crashes, writing the lowest part of the memory all with $20.

Is there any special "init" that I am missing? Please help, I'm stuck

[rhurst]

I am assuming your MAIN compiles to an address at or after $2000.

I also inspected the binary using VICE's monitor:

bl "fixed-3500.bin" 0 3500

d 381f 3881

...and nothing jumps out at me. Both VICFRAME1 = $10 and VICFRAME2 = $12 are correct page pointers to VIC's with 8k or more memory expansion.

I am certain you know this, but the RTS will fail, because it attempts to go back to the BASIC stub, and it has been since erased from the SSSINIT call ($1200 - $13FF are reserved for VICFRAME2). Could that be what you're running into?

You can always email me source/binaries to robert@hurst-ri.us

[nippur72]

Ok, got it working now, the error was due to my MAIN loaded at $1200 and not $2000, so it was erased by SSSINIT as you have guessed.

I still have some problems with timigs as it seems to be different between PAL and NTSC: I tried to compile your "sample.s" and in ntsc is perfectly smooth, but in pal is somewhat blocky (not much, but not as smooth as in NTSC). I tried both in VICE and MESS with similar results. I have checked synchronization between IRQ and raster and they are correctly synchronized (SSSIRQ is triggered at the end of the video page, as expected).

For some reason I see this different PAL/NTSC behaviour in your compiled version of "sample.s" (primer folder). Have you noticed this too, or is it my emulator not working?

[rhurst]

Glad to hear you cleared the first hurdle.

I have not experienced any blocky issues as you describe, although I am familiar with that result should the IRQ timing is not synced up properly first.

So there's good reason for that, because before you SSSINIT and (if you decide to) use SSSIRQ, you should use startup code like that supplied in BASIC-8K.s to synchronize the IRQ. Note, this is not my handy work, it is a merge of what Mike provided earlier and some source I found on the internet:

Code: Select all

MAIN:
		LDA MACHINE
		CMP #$05
		BEQ NTSC
		CMP #$0C
		BEQ PAL
		JMP RESET		; not a VIC?
		;
		; NTSC setup
NTSC: LDX #<@NTSC		; load the timer low-byte latches
		STX $9126
		LDX #>@NTSC
		LDA #$75		; raster line 234/235
		BNE IRQSYNC
@NTSC = $4243			; (261 * 65 - 2)
		;
		; PAL setup
PAL:  LDX #<@PAL		; load the timer low-byte latches
		STX $9126
		LDX #>@PAL
		LDA #$82		; raster line 260/261
		BNE IRQSYNC
@PAL = $5686			; (312 * 71 - 2)
		;
IRQSYNC:
		CMP VIC+$04
		BNE IRQSYNC
		STX $9125		; load T1 latch high, and transfer both bytes to T1 counter
		JMP RESTART

I suppose I could have just made that a part of SSSINIT, but I didn't want any issues from calling this initialization more than once. I like having the option of just cleanly re-starting the VIC software sprite stack with SSSINIT.

All the demo source code I provided require they are compiled with the primer project, which provides this IRQ synchronziation code, if you do not want timing issues.

[nippur72]

I've experienced the blocky issues in PAL even if I use the IRQ synchronization routine; but I suspect it's something related to emulation than anything else. I'll confirm that after some tests on a real machine.

As I've said in my previous message, synchronization seems to be ok, with IRQ correctly starting at bottom of video page (playfield). To check it I usually change the screen to black for some cycles, so I can visually "see" where the trigger point is. Another test I do is flipping 36879 between two values at IRQ call, so I can see if IRQ execution time is short enough. Doing it in my SSS example gives two different visual results in PAL and NTSC. Don't know why, perhaps because there are frame skips?

[rhurst]

Those are all good things to do. Sounds like you're on top of that. Just curious, which emulator/version are you using?

Since PAL refreshes less than NTSC -- and if you have the loop waiting for vsync -- then it should not frame skip more than NTSC (just the reverse can happen, although I have not seen that happen). How are you calling a flip operation? What's on the screen?

So, timing depends on what you pass the Y-register (> 0) to SSSFLIP, and depends on how many active (or sized) sprites you have. Typically, you pass Y=0 in game loops and >0 for animated sequences you want perfect timing for.

The other flip operation, SSSFFLIP, uses Y a little differently -- if too many vsyncs pass from the last flip (Y+2), it will render/flip the frame, but automatically skip that process on the next call. That allows game action to get more cycles at the expense of updating the display. In Omega Fury, it can have a lot of varying sizes and speeds of sprites (up to 5 ships + 7 shots + 2 explosion types simultaneously), so SSSFFLIP is skipping all the time. But frequently, the skipping is not perceivable, because the video changes only occur on sprites that make a call to SSSANIM / SSSMOVEXY -- because not all those sprites need to move or animate on every frame redraw. The player's ship can be the most susceptible to frame skip, particularly when it is flying at higher speeds and there other ships still active -- then a 2-pixel jump can be perceived. It's a tradeoff, but it is the best way to keep the pace of the game up.

[nippur72]

I have similar problems with Omega Fury (latest beta) emulated in Vice 1.22. Running the game in PAL is somewhat blocky. In NTSC it's smooth but "jumpy": sometimes there is a big frameskip, resulting in the spaceship jumping quickly from one location to another. Very strange. I tried several video configurations in VICE but none seems to do well. Any idea? I still have to check it on a real machine.

[nbla000]

Hi Nino,

Happy to hear you, it seems that you have some spare time for new games

There are a lot of peoples that now enjoy your games on Mega-Cart

[rhurst]

Any idea?

Not a clue.
I have not experienced anything that drastic. I'm running VICE 2.1 and a real NTSC VIC. It runs smoothest on a real VIC with a composite monitor.