Software sprites?

[beamrider]

Yes, that was it. I should have spotted that.

Thanks

[rhurst]

Are you kidding me? You've done so much of this on your own accord, and I hope you continue to have fun with this. Feel free to post some preliminary binaries in a game development thread -- the peeps here love to demo/watch a game unfold as it reaches new milestones.

[beamrider]

Thanks I'll post an alpha at some point when I'm on the home straight.

One thing I did want to ask. I'm using all multi color and some of the sprite colors are rendered behind the play field characters. Is there anything that can be done about this? I'm using SSSPRINT to print the background btw.

One thing I discovered yesterday was that a vertical floating sprite can be converter into a horizontal floating one of equal size by modifying the spritedef which has proved useful.

[tlr]

What's the current feature set/performance of this sprite library?

I'm very impressed by the games I've seen using it so far.

[rhurst]

One thing I did want to ask. I'm using all multi color and some of the sprite colors are rendered behind the play field characters. Is there anything that can be done about this? I'm using SSSPRINT to print the background btw.

No, there is no masking phase for multicolor sprites to maintain the integrity of its color. You might consider using 'ghost' mode (EOR) to at least maintain its shape, although the colors will 'invert' as it passes over background cells. Static cells always force sprites to go completely behind them, regardless if it is hires or multicolor.

One thing I discovered yesterday was that a vertical floating sprite can be converter into a horizontal floating one of equal size by modifying the spritedef which has proved useful.

Yes, defining the largest dimensions a sprite might be during runtime with SSSCREATE avoids complications later, as you observed, you can force a different dimension/behavior within the buffer container allocated for it. Note that you need not have to do that during runtime for all use-cases, as SSSUPDATE will optimally use the minimal number of characters for rendering and displaying within the allocated character pool during creation.

[rhurst]

What's the current feature set/performance of this sprite library?
I'm very impressed by the games I've seen using it so far.

Thanks, this post summarizes some, but the PDF document as part of the download archive is more detailed and comprehensive. Certainly the included Sprite Invaders game in it should provide for a broad stroke across the API and supporting features.

P.S., due to a Wordpress update, the download for it moved.

[beamrider]

Hi Robert

I have now posted some info about my game here:

http://sleepingelephant.com/ipw-web/bul ... php?t=6634

As you can see there is a request to increase the number of rows. I have just read your section on VIC Screen geometry in the vicSSS documentation, but am still a little confused.

a) Does increasing the number of rows require a commensurate reduction in the number of columns to retain the same number of cells?

b) if the answer to (a) is no, what adjustments would be required to DIRTYLINE and DIRTYLINE2 to support e.g. 26 rows?


Thanks in advance.

[rhurst]

Hi Robert

Hello! Been out of this picture for some time now, too many things to do before we take-off to Venice in September. Hope all is well with you.

a) Does increasing the number of rows require a commensurate reduction in the number of columns to retain the same number of cells?

Typically, yes, because VIC is limited to 2-pages (512 bytes). So 22x23 = 506. Changing it to 26 rows will yield 19 columns at most = 494. I changed the columns to 21 with 24-rows (504) in Quikman to improve the maze, score, and fruit levels to match better with the original.

A nice trick with VIC is to use those 'extra' unseen bytes not used for the display as custom VIC characters. For example, my QuikVIC Graphic Character editor has a flashing pixel block without touching the standard 64 custom characters used in a stock VIC.

I want to believe that Frogger is an example of getting the most out of a screen's viewable area, but an IRQ is timed to a fixed scanline, whereas some switching of VIC's registers point it to another page to extend upon the 512-byte limit. Someone more capable than me might comment on that.

b) if the answer to (a) is no, what adjustments would be required to DIRTYLINE and DIRTYLINE2 to support e.g. 26 rows?

Modifying that works if it remains within 512-bytes, as VIC-SSS runs under the assumption that the sprite window is confined to 2-pages, i.e., PLAYFIELD, PLAYCOLOR, and the 2 video buffers ACTIVE and PENDING. If you want the sprites to float over the extended portion, well, that's an entirely different matter.

[metalfoot76]

Wow. I'm on a huge Commodore kick lately, though I only own a couple 64s and a 128, and I had no idea you could do such things with the VIC. This is awesome. Downloaded your SSS package and might fiddle around with it under CBMPrgStudio.

Sprites, working, fluidly, on a VIC. Who would have believed that in 1983?

[beamrider]

Hello! Been out of this picture for some time now, too many things to do before we take-off to Venice in September. Hope all is well with you.

Thanks for reply, all is good. Venice is fantastic, you'll enjoy it!

Pooyan is coming along nicely as well

[Mike]

Typically, yes, because VIC is limited to 2-pages (512 bytes). [...]

Actually, it isn't. You can easily define, say, a 26x32 characters screen and use all 832 bytes. That's what Torsten and I used all the time to provide the address generating text screen for the overscan bitmaps we did lately, but you can of course still do a normal text screen (+sprites).

Only slight caveat: if you use a screen base at a half K boundary, and the screen size exceeds 512 bytes, the colour RAM will wrap from address 38911 to 37888 ...

Edit: ... and if you're working with double-buffers then you can't use it sensibly. Because even though you can have two screens with more than 512 characters, there's only one colour RAM with 1024 (half-)bytes in total.

[pallas]

Hello! Been out of this picture for some time now, too many things to do before we take-off to Venice in September. Hope all is well with you.

Thanks for reply, all is good. Venice is fantastic, you'll enjoy it!

Yes but hurry up, the weather is changing!
Not that Venice is less beautiful when it's raining...

[tokra]

Sprites, working, fluidly, on a VIC. Who would have believed that in 1983?

Not to diminish the recent work, but look at the classic "Jupiter Lander" for example. Smooth moving objects (= pseudo sprites) in what I believe to be one of the first VIC-20 games.

Or look at the 3 Imagic-titles Atlantis, Demon Attack and especially Dragonfire. All three use raster effects and Dragonfire even has a hires-player-sprite with 3 colors vertically that can even jump and all this with nearly no color-clashes. This feature not only uses vertical raster effects but horizontal ones as well. The second level of this game uses color ram changed on vertical raster position for its objects, something I just recently did with the VIC20-FLI-modes. On top of that the games works in NTSC and PAL which have completely different raster timing. It doesn't get much better than that! You can see the programmer obviously went through the hard school of Atari VCS-programming where raster exact programming really is a must rather than an option.

Or look at Capture the Flag (NTSC). Not only one, but TWO smooth moving 3D-labyrinths side by side.

So in essence I would say the best programmers back then were just as talented as today.

[rhurst]

Right on, tokra! My VIC-SSS doc specifically accounts for the fact you cannot beat a tightly-written ML procedure to make for a specific graphic effect. And as I have said before, different objectives drive different solutions and results: back then it was all about time-to-market demands, while now it is a leisurely endeavor. Those titles you mentioned were really special in the home computer scene, and only inspired me to become a systems and software engineer.

Mike, thanks for clarifying, but could you dump how the VIC registers might look to accomplish that >512-byte screen space? I would not mind seeing that in action, and perhaps account for it in macro assembly?

[Ghislain]

And as I have said before, different objectives drive different solutions and results: back then it was all about time-to-market demands, while now it is a leisurely endeavor.

I agree with this. Using a modern PC with all of it's GUI tools and emulator makes writing software on 8-bit platforms much, much easier. Plus, we have the internet to look everything up. In fact, I find it quicker to just make a Google search instead of shuffling through the VIC-20 Programmer's Reference Guide.

For example, to design my latest 3D viewport for Realms IV (in 24K mode), I used a spreadsheet in Open Office to make the data tables for each of the components of what's displayed on the screen and then used formulas like =".byte " & C1 & "," & C2 (etc) so that the data could be copied and pasted into the .s file. How long did it take me to do this? About 2 days (3 hours a day). I think this would have taken much longer to do if I was programming this way back in 1983 with only an ML monitor and scrap paper. It might have taken me 2 weeks, if not longer!

I really don't know how they did those games back then, to be honest. They had to be geniuses, or pretty damn close to being geniuses. I read the Stella Programming Guide (for the Atari 2600) about ten years ago, and these guys must have been dreaming in raster mode while constantly chasing the beam. After reading it, I developed a new apprpeciation about how Atari 2600 programmers were able to create amazing games IN SPITE OF the limitations that they were faced with. Even the crappy Atari games with lots of flicker were still pretty hard to do.