Software sprites?
Moderator: Moderators
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Ok, first ALPHA release DEMO of these "software sprites" is available.
Download it here:
DEMO cartridge @ $A000
... and its assembler source code using cc65 project.
It supports NTSC (default) with a startup override to switch to PAL timing. Press RUN/STOP to pause frame.
Still 8x8 only, and just the "fixed" and "vertical" modes supported -- "horizontal" and "float" modes to follow. Then the double-width, double-height, double-both will follow that.
I am very pleased with its progress. The API is coalescing into something that might be useful for rapid implementation within video games, or even just to add some animated effects.
Feedback is always welcomed.
Download it here:
DEMO cartridge @ $A000
... and its assembler source code using cc65 project.
It supports NTSC (default) with a startup override to switch to PAL timing. Press RUN/STOP to pause frame.
Still 8x8 only, and just the "fixed" and "vertical" modes supported -- "horizontal" and "float" modes to follow. Then the double-width, double-height, double-both will follow that.
I am very pleased with its progress. The API is coalescing into something that might be useful for rapid implementation within video games, or even just to add some animated effects.
Feedback is always welcomed.
I tried this in VICE and was really impressed.
I'm not a good programmer, and have not tried hi-res graphics (beyond custom characters), so the following question might be naive. But I noticed that when certain sprites crossed (i.e. the red flying arrows crossed over or under the blue ghost) the colours did not clash.
How were you able to accomplish this? I thought the only way to define each pixel in proximity as having a separate colour was to use "fat pixel" multicolour mode. In true hi-res single pixel mode, I though colours could only be defined for something like a 16x16 pixel area. i.e. you see this happen in the game "Cosmic Cruncher" (or even your Quick Man game) where when the player's character goes near something of another colour, the colours "bleed".
But in your demo, when the arrow passes under the ghost in your demo above, and you can see pixels of the arrow throuh the ghost's eyes, etc. all pixels of the ghost stay blue, and those that show through of the arrow are correctly red.
I thought this was impossible on the VIC.
I hope you can understand what I am asking.
I'm not a good programmer, and have not tried hi-res graphics (beyond custom characters), so the following question might be naive. But I noticed that when certain sprites crossed (i.e. the red flying arrows crossed over or under the blue ghost) the colours did not clash.
How were you able to accomplish this? I thought the only way to define each pixel in proximity as having a separate colour was to use "fat pixel" multicolour mode. In true hi-res single pixel mode, I though colours could only be defined for something like a 16x16 pixel area. i.e. you see this happen in the game "Cosmic Cruncher" (or even your Quick Man game) where when the player's character goes near something of another colour, the colours "bleed".
But in your demo, when the arrow passes under the ghost in your demo above, and you can see pixels of the arrow throuh the ghost's eyes, etc. all pixels of the ghost stay blue, and those that show through of the arrow are correctly red.
I thought this was impossible on the VIC.
I hope you can understand what I am asking.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Are you pressing RUN/STOP (or PC's ESCape key) to pause the frame to see that? If you are, then VICE is not emulating it properly. Is video cache off and is refresh set to 1/1? Other settings could be affecting the correct rendering -- it is nothing a real VIC is capable of.... and those that show through of the arrow are correctly red.
I do some overlaying by writing two different characters / colors on separate video/color maps, then switch when the raster is outside the viewable area (thanks Mike). Such as the green + and cyan * on the first screen and the colored ball/circle targets on the second (which the balls are erased when struck by a weapon.
When I am done with this and write a full-featured demo and its API documentation (for all to embrace ), I will then re-write an 8kb version of Quikman for every feature imaginable and I want to then write two more titles: a Satan's Hollow clone and Omega Fury sequel to Omega Race.
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
I found the right char of the arrow flying to the left was missing. But I didn't notice, well, the absence of colour clashes - as ral-clan reported. Persistence of vision? (I'm using VICE 1.16, btw)
How about ... Gyruss?rhurst wrote:I will then re-write an 8kb version of Quikman for every feature imaginable and I want to then write two more titles: a Satan's Hollow clone and Omega Fury sequel to Omega Race.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
This version won't work on unexpanded VIC right now, though I will strip (or conditional) out to make it into a "lite" version to run on unexpanded. I have another sprite routine already written from 24+ years ago that supports 8x8 within a 2x2 character cell matrix for unexpanded VIC -- hacked down to fit into Quikman 1984.What is max # of sprites and will the sprite library work for unexpanded vic ?
This works with any 8k+ RAM expansion, or just load the code into the game cartridge ROM space and use stock RAM. Conditional assembly could be setup to allow for a 3k only expansion version, i.e. adjusting for the different ACTIVE / PENDING video addresses.
There is a limit of 128 custom characters (because I choose to keep the 128 ROM characters in play). Double-buffering means up to 64 chars can be visible at once (without potential corruption on the active display). In theory, 64 missile sprites, or 16 floating 8x8 sprites, or 7 floating 16x16 sprites (7x9=63 chars) plus 1 missile, etc., combinations are possible. And Sprite definitions can be changed dynamically at run-time as needed.
Of course, you will probably want some custom chars for the playfield, so there is a MAX variable to set to put a ceiling on what the sprite routine can take from. As that number is lowered from 128, so it affects the size and number of active sprites.
That was intentional on that version. It only displays 8x8 fixed or vertical only matrices now... and the left flying arrow is going horizontal, so it is image rotated within an 8x8 frame.the right char of the arrow flying to the left was missing
The 3 bullets (1x1 pixel, 1x2 pixel, and 2x2 pixel) demonstrate the use of missile graphics within an 8x8 frame. The left flying arrow showed me that an interesting effect can be made by using a larger image, i.e., it looks like its "tail" is a flickering flame and it never loses its "point".
Same with the vertical arrow, although I toggle its "vertical" attribute every other column to demonstrate with and without the overflow character beneath it. So, its tail flickers on one column, but is solid on the next.
I replaced the entire rendering and display routine last night, so it will work with all display modes:
8x8 fixed, horizontal only, vertical only, both
8x16 fixed, horizontal only, vertical only, both
16x8 fixed, horizontal only, vertical only, both
16x16 fixed, horizontal only, vertical only, both
The rendering and display is smart enough to work only within the sized frame required, reducing machine cycles and potential color clash. So the a sprite matrix can occupy as little as 1 character cell or as many as 9 (3x3).
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Major update... and this code might even turn out to be done, but for now, I'll call it a Release Candidate. And only because I did not complete its programmer's documentation (yet), and I now need to write a full game using it, instead of the simple demo that's included.
Download the zip file folder, unpack, and attach demo.a0 as a cartridge to your favorite VIC emulator.
I don't have my Mega-Cart yet, so I can't ( or won't ) help those who do have them ...
Enjoy!
P.S., if this FULL-BUFFERED code turns out to be complete, I will use it as a baseline for the FAST-BUFFERED version, followed by a LITE version.
Download the zip file folder, unpack, and attach demo.a0 as a cartridge to your favorite VIC emulator.
I don't have my Mega-Cart yet, so I can't ( or won't ) help those who do have them ...
Enjoy!
P.S., if this FULL-BUFFERED code turns out to be complete, I will use it as a baseline for the FAST-BUFFERED version, followed by a LITE version.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Release Candidate 2 is out and can be downloaded here.
Some minor bug fixes only, as its code execution is working out great. I started a programmers PDF document, but it needs a lot more work.
In addition, I integrated the new Software Sprite Stack (SSS) into a copy of the QUIKMAN 4kb ROM source -- it is now an 8kb ROM cartridge, with plenty of room to add more fun features. The quikman-8k.a0 binary and source are part of the ZIP archive.
So it now runs flicker-free!! But note, to keep the playing speed up for arcade style play, I enforce VSYNC only during attract mode and between levels, and not during run-time. But the overall video is much better, without sacrificing on performance.
Also, I am certain this integration has introduced some new bugs in Quikman -- I just ran out of weekend to complete my testing, so file bug reports if you find any. Thanks and enjoy.
Some minor bug fixes only, as its code execution is working out great. I started a programmers PDF document, but it needs a lot more work.
In addition, I integrated the new Software Sprite Stack (SSS) into a copy of the QUIKMAN 4kb ROM source -- it is now an 8kb ROM cartridge, with plenty of room to add more fun features. The quikman-8k.a0 binary and source are part of the ZIP archive.
So it now runs flicker-free!! But note, to keep the playing speed up for arcade style play, I enforce VSYNC only during attract mode and between levels, and not during run-time. But the overall video is much better, without sacrificing on performance.
Also, I am certain this integration has introduced some new bugs in Quikman -- I just ran out of weekend to complete my testing, so file bug reports if you find any. Thanks and enjoy.
- Pedro Lambrini
- Vic 20 Scientist
- Posts: 1132
- Joined: Mon Dec 01, 2008 11:36 am
Slightly OT but I love the new Quikman-8K. Is there any way to run this on a real Vic, at all? I have a uIEC... Thanks
PS: If the tech quality of Quikman is anything to go by you really are onto something here and can't wait to see what delights the talented folk (read: not me!) around come up with.
PS: If the tech quality of Quikman is anything to go by you really are onto something here and can't wait to see what delights the talented folk (read: not me!) around come up with.
"...That of the Eastern tribe being like a multitude of colours as if a rainbow had settled upon its brow..." Daniels 1:3
- Mike
- Herr VC
- Posts: 4888
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
This one happened to me at the begin of the third round:rhurst wrote:Also, I am certain this integration has introduced some new bugs in Quikman -- I just ran out of weekend to complete my testing, so file bug reports if you find any.
http://cid-05ef0a8eae2a4f4a.skydrive.li ... uikmen.png
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
For now, if the binary can be loaded into an 8K RAM spot located @ $A000, I don't see why not. I am planning on making an alternate STARTUP segment, and re-compile this assembler source to load on a regular 8k expanded VIC as a normal PRG binary, with the customary 1-line BASIC SYS call.Is there any way to run this on a real Vic, at all?
Me neither! Once I am settled on the API, I want to work on those other game title, in particular, Omega Fury.... and can't wait to see what delights
Oops! But, you got 255 lives, and you're complaining?quikmen.png
Seriously, if you want to achieve higher scores, I would suggest changing the FRUITSCORE table and make the Cherry = $50 (80 x 100) to start off with.
There is another bug from clipping -- you can start eating maze walls from exiting the tunnel right with a buffered DOWN event -- munch away! My PEEAKAHEAD logic needs a little work on wraparound.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
It was started, my liege, but I had to see it in action first before I got too carried away. My comfort level with it has been raised, so I will complete the documentation, with clear examples and (hopefully) worthy considerations.nippur72 wrote:are you working on the API documentation too?
While I have no realistic expectations outside my use of it, I don't like leaving this type of source code lying about without purposeful documentation. When it is ready and if you take some time to read it, I would appreciate feedback on its completeness and usefulness, too.
Thanks.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Release Candidate 3 is out and can be downloaded here.
Not so much as NEW code for VIC-SSS, but I wanted to get this out for others that were asking:
- a BASIC PRG loader for VIC's with an 8k expansion RAM (BASIC.s assembler source and ld65 configuration file), so games can be simply compiled for an 8k ROM cartridge (using A0CBM.s to create yourgame.a0) or +8k VICs (using BASIC.s to create yourgame.prg)
- fixed some bugs in quikman-8k.s and re-compiled for both .a0 and .prg binary formats.
Keep the feedback coming, I appreciate it!!
Not so much as NEW code for VIC-SSS, but I wanted to get this out for others that were asking:
- a BASIC PRG loader for VIC's with an 8k expansion RAM (BASIC.s assembler source and ld65 configuration file), so games can be simply compiled for an 8k ROM cartridge (using A0CBM.s to create yourgame.a0) or +8k VICs (using BASIC.s to create yourgame.prg)
- fixed some bugs in quikman-8k.s and re-compiled for both .a0 and .prg binary formats.
Keep the feedback coming, I appreciate it!!