I'm still trying to figure out how to programme a sprite routine in ML. Is there anything somewhere that explains some of the tricks people use to create smooth, pixelwise movement? I'd like to do something that a big single coloured sprite á la Jupiter Lander... This particular game doesn't look as if it moves on a screen that is completely a bitmap.
I'm also looking for hints how to produce sounds, synchronised with movement on the screen.
Could it be that the successful programmers of those stunts have always been quite secretive about their tricks? Could it be the time now to let us lesser mortals have a glimps?
I'm also interested in good software sprite routines. I know a number of games and some demos have them, but it varies how useful they are. Basically, if you have a "sprite" that is 8x8 pixels, I believe you would create a box of four characters where you plot the "sprite" within, and then move the box around the screen as appropriate. Then you keep in mind any other movable or still items that have to be drawn within the box too.
The keys are to make as little flicker as possible, to detect collissions, to be able to handle several movable objects at the same time. And of course, to take the colour clashes into consideration. Even if you work in the lower resolution multi-colour, at one point or another you may get a colour clash when two objects of different colour are supposed to be in the same part of the box.
On the VIC you have only the possibility to display redefined charsets on the screen.
For some sprite-movement I recommend
1. redefined charset which is a copy of the regular charset
2. real-time pixel-movement and saving the pixels /colors below the actual 'sprite'
AFAIK there has been an article about sprite-simulations in an early COMPUTE!- issue around 1983.
Perhaps somebody can dig in his/her archive and take a look.
Pixelwise movement: Look at early space-invaders games. They use smooth-scrolling with really good pixeled characters.
Synchronisation with sound:
LDA 36876
CMP #frequency
BEQ effect@frequency
Just polling the contents of the sound-registers, and jumping in a special-effect-routine.
Polling can be done each IRQ (change $0314/$0315 to the new routine), but don't forget to set a control-bit when the effect is running that you don't enter the effect-routine more than one time ....
It's actually fairly common knowledge, because the same tricks that the VIC uses have been utilised for the 264 series and, to a degree, for the bitmap-based machines like the Spectrum and CPC. There's a myriad of variations and sneaky work-arounds for specific graphics, but essentially, you move little bitmapped areas around, so assuming you have a player object that's eight pixels across and sixteen down, you'd have a work area that was 8 pixels bigger on each axis. F'example, we could use the characters A through to F in a redefineable font, arranged this way;
AD
BE
CF
Vertical positioning is easy because all we need to do is write into the font data at the right offset, the offsets are 0 to 7, then our character block moves vertically and it starts again. Horizontal is a bit more difficult because there's a couple of possible ways to do it; either we write the graphic in at the left hand side and perform the relevant number of LSR / ROR commands to shunt it over, use a slightly more "intelligent" approach that works out which side is closer to the correct position and LSR / ROR or ASL / ROL accordingly or, if memory isn't an issue, have all eight possible states pre-calculated and switch them in accordingly.
As a good example of the latter, check out how miner Willy is animated (i believe this applies to Perils of Willy and it's certainly how Manic Miner does it on the machines without hardware sprites) because his eight frames of walking are all offset by a pixel and, as he animates, he moves from one character cell to the next.
Some VIC games take that a step further though, the player ship in some of Jeff Minter's games move are four pixels a refresh and have two possible states hardwired into the font (Hellgate does this, if memory serves, for the player, nasties, goats and so forth) so there's no complex redefinition to handle and everything can be hammered around at very great speed just by writing to the screen RAM.
There's nothing to stop you playing mix and match too; nasties precalculated, the player generated on the fly so it can be ORA'd into the background and nasties... =-)
Thanks for all your posts! I think I need a more hands on approach, something with sample source codes, so that I don't have to re-invent the wheel. I'm sure there are many routines that are the same for everybody who tries to do this...?
My routines tend to vary depending on what i'm doing, at the moment i've not needed a full ORA'd soft sprite routine for a VIC game so i don't have any source, sorry...
I was thinking and mulling over on about a way to create C64-style sprites on the Commodore VIC-20.
It would consist of an ML module that would use the IRQ jump address (at $314) and plot the sprites on the screen.
Features:
-6 sprites of 16x16 onscreen, 64 total sprites defined in memory
-registers for all six sprites for X,Y position
-registers for collision with other sprites
-registers for collisions with the background
-registers for colors
-registers to determine if the sprite will overwrite, XOR or OR it self with the background custom character
-internal registers to determine if the sprite will move or not (why redraw the sprite 60 times a second if it is moving slowly or staying in place?)
So each sprite will use 32 bytes for data and an additional 72 bytes of character memory if they're on screen (say sprite collides with a custom character shaped liked an X--you only want that X on the screen to change and not the other X's). Of course the game developer who is using this module would have to be aware and should take into account that by directly peeking the screen memory, that he might return the value of a custom character that is of a sprite--and there will be registers that he can look up to see what is really there. I might just duplicate the entire 506 bytes of screen if this process is too complicated.
One monkey wrench is--what to do when two or more sprites collide and share a location with a background custom character? Maybe just have the second sprite share the "what's behind the sprite" values and just XOR/OR or replace the 8x8 screen area.
Sprites have been "simulated" in many VIC-20 games, but there has never been a standardized "module" to be shared in the VIC community. Everyone pretty much reinvents the wheel every time according to their needs.
Is this too ambitious a project? At bare minimum, 8K of memory expansion will be needed. If were to write it, I'd definitely share the source code so that others could improve on the inefficiency of my code (I'm not a very strong ML programmer).
===========================================
This has brought back the memory of a story of when I went to a friend's house and saw the type-in program of the balloon sprite in the C64 user's manual. I typed it in on his C64 and when I ran the program I thought that was one of the most awesome things I ever saw. So I borrowed his user's manual and went home to type in that program on my VIC-20 and to my disappointment at the time--it didn't work, lol.
"A slave is one who waits for someone to come and free him." -- Ezra Pound
[quote="Ghislain"]Is this too ambitious a project? At bare minimum, 8K of memory expansion will be needed. If were to write it, I'd definitely share the source code so that others could improve on the inefficiency of my code (I'm not a very strong ML programmer).[/quote]
No, it sounds like a great idea. Remember not too long ago we all thought the vics sound was only capable of square waveforms. Now we know diferent. Not threw a hardware upgrade, but a software technique. I'd like to see the vic get some new sprite commands.
btw, A game was published for the vic20 (also on the c64 in Feb. 1984) called AstroPanic in Compute's Gazette (April 1985) that boasted about Vic sprites. I think it was more of a bit map thing though. Also, I noticed that the program is on funet. The article offers little info on the subject, but maybe you could disassemble the program and see how this guy(16 at the time) did it.
The other night I struggled for over an hour trying to get just one pixel to smoothly float across the screen. I gave up. I kept having a really dumb problem where every character space across had the floating pixel.
I've been meaning to regroup and try again but I'm always doing something....
But I definitely got my crazy ideas about what i could do with sprites in an unexpanded vic..
I see this is a very old thread, but first time I've read it, so thought I'd just add a comment.
The book Compute's Vic-20 Collection, which I own, has a program called sprite sprite-imation which provides 4 sprites for the vic. These are 16x24 bit sprites, they can be multicolor, they have variable sprite to sprite priority and sprite-sprite collision detection, as well as sprite-background collision detection.
It's a very interesting program- you enter in a program with 8k or greater expansion and then run it and it creates a machine language program and saves it to tape or disk. This machine language program is the actual sprite program and requires no memory expansion itself to work.
It's a pretty slick program. I had it on disk years ago, but alas, my 1541 is pooped and I didn't transfer to 64hdd before it happened...
Still have the book though...
If no one has it and there is interest, I could <grrr> re-enter it into the vic, or maybe scan the article and post it.
viclizard wrote:It's a pretty slick program. I had it on disk years ago, but alas, my 1541 is pooped and I didn't transfer to 64hdd before it happened...
Sounds nifty. Did the disk die too? If not, you could mail it to one of us willing folks to transfer... sounds a lot easier than typing that in again.
I don't think a one-solution-fits-all is ideal for the VIC, since there are so many variables when doing a sprite routine.
Speed vs. memory trade-offs is the biggest one, plus whether proper overlap/transparency is necessary, plus whether collision detection is necessary (and if so, how accurate?), etc.
A generic routine is fine for a game that doesn't push the VIC much, so it certainly has uses. But if you want the game to run with little or no memory expansion, or you want it to run smooth (and correspondingly run at a high frame rate, so to speak) then you need a more specialized routine.
Nope.
As a matter of fact, I aligned my 1541 this past weekend and it's working now. First time I ever did (or tried) that before, so feeling pretty happy about it. I've got a few more 1541s out of alignment in the closet I'm going to have to bring out and align now that I've had one success.
I used instructions and program I found in a book "1541 user's guide The Complete Guide to Commodore's 1541 Disk Drive" by Dr. Gerald Neufeld.
So, now I have the program again, and maybe a few others I haven't seen on the net anywhere else.
Is there someplace to upload this stuff and scans (the chapter that has the instructions for the sprites and I was thinking I should put the alignment program and a scan of the instructions for it up somewhere as well. I looked around a bit on the net and couldn't find one so i typed this one in from the book and it worked pretty well). + maybe a few odds and ends from my disks. I didn't have a lot, but maybe a couple of things there that are fun that aren't found on the web yet.
I still have to pull out the scanner- I haven't had it hooked up in a few years. I guess I wouldn't get in trouble for scanning the relevant chapters and making them freely available from anyone?...
Only downside to the sprite program- it looks like it doesn't work with ram expansion beyond 3k... Someone who is really good with ml could probably "fix" it though.
The demo for it is very simple and only uses one sprite, but looks like it would work well for basic games and stuff.
________
Last edited by viclizard on Wed Feb 16, 2011 6:44 pm, edited 1 time in total.
