Software sprites?

Basic and Machine Language

Moderator: Moderators

User avatar
beamrider
Vic 20 Nerd
Posts: 821
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Postby beamrider » Thu Jun 27, 2013 4:17 pm

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

Thanks

User avatar
rhurst
Omega Star Commander
Posts: 1304
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Office of the CIO

Postby rhurst » Fri Jun 28, 2013 4:08 pm

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. 8)
Any technology distinguishable from magic is insufficiently advanced. See also magic.

User avatar
beamrider
Vic 20 Nerd
Posts: 821
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Postby beamrider » Sat Jun 29, 2013 6:37 am

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.
Last edited by beamrider on Sat Jun 29, 2013 12:20 pm, edited 1 time in total.

tlr
Vic 20 Afficionado
Posts: 438
Joined: Mon Oct 04, 2004 10:53 am

Postby tlr » Sat Jun 29, 2013 11:57 am

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. :)

User avatar
rhurst
Omega Star Commander
Posts: 1304
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Office of the CIO

Postby rhurst » Sat Jun 29, 2013 5:53 pm

beamrider wrote: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.
beamrider wrote: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.
Last edited by rhurst on Sat Jun 29, 2013 5:58 pm, edited 1 time in total.
Any technology distinguishable from magic is insufficiently advanced. See also magic.

User avatar
rhurst
Omega Star Commander
Posts: 1304
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Office of the CIO

Postby rhurst » Sat Jun 29, 2013 5:57 pm

tlr wrote: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. :D

P.S., due to a Wordpress update, the download for it moved.
Any technology distinguishable from magic is insufficiently advanced. See also magic.

User avatar
beamrider
Vic 20 Nerd
Posts: 821
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Screen Geometry

Postby beamrider » Mon Aug 12, 2013 1:48 pm

Hi Robert

I have now posted some info about my game here:

http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.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.

User avatar
rhurst
Omega Star Commander
Posts: 1304
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Office of the CIO

Re: Screen Geometry

Postby rhurst » Thu Aug 22, 2013 6:18 am

beamrider wrote: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.
beamrider wrote: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. :)

beamrider wrote: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. :twisted:
Any technology distinguishable from magic is insufficiently advanced. See also magic.

metalfoot76
Vic 20 Amateur
Posts: 63
Joined: Fri May 31, 2013 10:37 pm

Postby metalfoot76 » Thu Aug 22, 2013 7:05 am

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?

User avatar
beamrider
Vic 20 Nerd
Posts: 821
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Screen Geometry

Postby beamrider » Thu Aug 22, 2013 1:29 pm

rhurst wrote: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 :D

User avatar
Mike
Herr VC
Posts: 2993
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Screen Geometry

Postby Mike » Thu Aug 22, 2013 1:55 pm

rhurst wrote: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. :(
Last edited by Mike on Fri Aug 23, 2013 8:22 am, edited 2 times in total.

User avatar
pallas
Vic 20 Devotee
Posts: 212
Joined: Mon Dec 24, 2012 2:38 am

Re: Screen Geometry

Postby pallas » Thu Aug 22, 2013 2:27 pm

beamrider wrote:
rhurst wrote: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... ;-)

User avatar
tokra
Vic 20 Nerd
Posts: 812
Joined: Tue Apr 27, 2010 5:32 pm
Location: Germany

Postby tokra » Thu Aug 22, 2013 3:08 pm

metalfoot76VIC wrote: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.
Last edited by tokra on Fri Aug 23, 2013 1:50 am, edited 1 time in total.

User avatar
rhurst
Omega Star Commander
Posts: 1304
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Office of the CIO

Postby rhurst » Thu Aug 22, 2013 7:42 pm

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?
Any technology distinguishable from magic is insufficiently advanced. See also magic.

User avatar
Ghislain
Realms of Quest
Posts: 1065
Joined: Sun Aug 08, 2004 12:54 am

Postby Ghislain » Fri Aug 23, 2013 1:03 am

rhurst wrote: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.
"A slave is one who waits for someone to come and free him." -- Ezra Pound


Return to “Programming”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests