PeteD

I was trying not to confuse the guy If you're talking every byte counts, use zero page indirect instead. There are hundreds of ways to do it if you want to save ram or cycles. I think it's better to wait till the OP can draw chars to a screen before asking him how long he wants it to take

Bleugh my weird ass monitor made it look like that sprite scroller wasn't in the lower border lol I thought it was just over a couple of lines of chars.

Still not working with Vice 2.0. Or at least I hope it isn't Please tell me it isn't supposed to be flickering like that? including the colour splits on the side borders? I don't think Crest would produce something so ugly. I think if you're seeing flickering anywhere then it isn't working.

@andym00 You're confusing sid versions (6581 and 8580) with the fact that even on 6581 you couldn't count on the filters being the same from one machine to another. They seemingly just used whatever capacitors (or resistors, whichever, my electronics brain is broken) were available when they manufactured them

Because its using sprites over chars on the c64 it's barely any cpu time. Smooth scroll the background gray chars, it's a repeating pattern so when it gets to the 8 pixel limit just push it back to 0 again, then move the sprites over the top, sprites 0-7 then when 1 sprite has gone off screen 1-7,0 (move 1st one to the right side) then 2-7,0-1. I don't think it's rotating through the sprites (something that most oldschool sprite scrollers did). If it was it would actually be easier to do the variable width stuff but it still isn't difficult. That last part doesn't work on vice or ccs64 I really wish I still had my C64 I think the scroller in the middle is just hires with some colour ram being changed to make a pattern, don't think it's using this new mode.

@Rybags You're right about it being not much use, as I said they say it uses all cpu cycles per line. I think it's more than putting sprites beneath the picture though. Afaik it uses ifli too (tricking the hardware into fetching more colour ram so you can have more than 4 colours per 8x8) and they mention it also needs to use some sprites to cover the ifli bug (you don't get the colours you want at the start of a line with ifli). Also doing a variable width scrolltext is easy, I did some back in the 80s It's using sprites for the scrolltext with chars beneath for that parallax effect. @emkay I think it's supposed to sound "muffled" lol A lot of people use filters on purpose to create that effect, something that the C64 was good at but far too much difference between machines. You couldn't rely on a filter being the same on two C64s sitting next to each other.

If you just want to fill it with one character you can do something simple like this (presuming the screen is 40x24) LDA #character LDX #0 LOOP STA screen,x STA screen+240,x STA screen+480,x STA screen+720,x INX CPX #240 BNE LOOP RTS If you want to fill different size screens then you can change the +240 values and the CPX #240 That basically divides the screen of 960 (40*24) bytes into divisions smaller than an 8bit counter can handle, in this case 240 and you need 4 (960/240) STA instructions. If you're using a 20x24 screen you can just remove the last 2 STA lines and it'll fill the screen still because 20x24=480 max loop is 256 so use a 240 loop again then 480/240=2 so 2 STA instructions. Of course screen in that code is the base address of where your screen is in ram. Hope I didn't make my explanation too confusing Pete

Well for starters if you're not a musician you've done a better job than I ever could. I do class myself as a musician but have NEVER been able to compose stuff on a computer (at least not until the advent of the DAW)

Not bad for pokey but really doesn't compare to the c64 one in that demo.

Very nice Pretty useless apart from displaying pictures, at least for now till someone thinks of something clever to do with it but with precise timing and 0 cpu free I don't think there will be a lot. Probably just playing around with the bitmap contents to produce some effects. I don't think the poor C64s fixed palette will ever change It's not something that software can alter apart from doing the old trick of putting certain colours next to each other to produce a pseudo 3rd and that looked awful back in like 1984 or whenever I first saw it.

Sprites sprites sprites lol I thought we'd agreed not to go on about them any more I could type up a reply to your list with rebuttals and equal or greater comparisons to the C64 sprites but then it'll look like I'm being argumentative again

The way I've done it in the past is the way that works easily if you're redrawing the whole screen and sprites every frame (something I had to do on PSX) but the theory behind it is the same as seeing if you've got to mask rather than overdraw. You work out where the player sprite is based from where he is standing (taken from the bottom right corner of the sprite) compared to where the object is drawn (taken from the bottom right corner) if the player has a greater x,y pos (in iso I always see the X,Y as being normal 2d space not 2.5D or whatever you want to call it) then he must be in front of that object. I've not explained it very well there but just take into account that when building the screen, to make everything appear in the correct place you have to work from the back left to the front right. So it's actually very easy to sort that case where he;s in front or behind the tree. Theres no need for tables as such using this method, no extra checks or anything.

Definitely think people shouldn't be looking to just copy c64 games over. If the A8 can do something in a better way then go for it.

hehe Don't worry I'm not going anywhere.

I totally agree masking the sprites in that way is the way I would've done it, will do it if I have ago and seems the easiest way, weird though that sprites are being made with the tops of rocks in them in ram. It's been a loooooong time since I played LN but from the screenshots I've seen and the quick play I had this morning there is barely anything the players can go behind. If that's the case then if only to save ram it might be better to have a coarse check then a mask. eg player is at 100,100 and is 16 wide,20 tall, shift that all down to 8x8 checks for the, err, coarseness, then if there is anything there you can use that (or those) bytes as an index to the actual mask data, 1 = big rock, indirect that to address of rock data with a header giving its dimensions. No use having screen sized masks if 95% of it is clear. I think I see what you're saying about not mattering which frame the player is displaying but that wouldn't make much difference anyway. Anyway, I ramble again, whichever way it was done and whichever way it should be done it's going to be up to whoever codes it to just make it work. More important I think is how to get the colours on the screen. Speaking of which I keep reading people saying the info panel should be moved to the left of the screen. Having not read all the gumph on the A8 yet I've only got a simple idea of why this is a good idea. Something to do with the cycles available later in the screen for messing around with stuff? Pete

Agreed, I for one promise not to argue any more Everyone has an opinion and I'm happy to be here getting involved with the A8 community. Maybe this thread wasn't the best for me to start with Pete

Just checked LN in Vice with a cartridge image attached that has a sprite viewer. It looks from first viewing that the masks are made of sprites but just stuck on top of everything else. I found something looking remarkably like the top of a rock when I stood the player behind a rock. There were actually a couple of sprites very similar looking so it's possible it uses more than 1. Anyway, software still gets my vote I'll be messing around with vb.net some more today as I need some PC tools for other projects anyway so once I can get file loading/saving, a bitmap screen displaying with the ability to draw pixels to it (I have some code for that in .net somewhere) I'll pretty much have everything I need to start looking at the LN editor BUT it isn't my top priority, will just happen if it can although I do hope I have the time to help out.

I gave algorithm for 2000+ sprites in this thread. C64 has to update a lot more registers and has less time. Atari wins. QED. Come on dude, 2000 sprites with what in them? a pixel, a line? Sprites that are any use for something would be a fairer comparison. If I'm not wrong (and I'm quite sure someone will be quick enough to tell me) A8 sprites are 1bpp 8 pixel wide (not including expanding them to double or quadruple the size) and mono, to make them MC you need to overlay 2 of them. So to reproduce a c64 sprite you need 6 and c64 has 8 of those to a line. That is the difference between the machines. Without any extra work the c64 trounces the atari on sprites. Usable ones that can be seen in a game, all on the same line. Where the A8 wins out to some extent is the vertical positioning of them but even then if they begin to overlap you're screwed again. So every game with more sprites on the A8 than the C64 they can only really change X position safely.

I can't really agree with the more sprites thing either. 8 per line as standard, call an interrupt and you've got another 8, do that as many times as you want, fill the whole screen with sprites, not a problem. They're also wider. it must be harder to repeat the sprites horizontally on A8 than it is to repeat them vertically on c64. Then you've still got to have an interrupt in the correct place to change the X position an A8. Also, can you alter the sprite definition ram pointer? or do you have to copy/move data around to change the Y all the time?

More likely what country you're from

Urk, told u it'd been a long time hehe. Yeah looks like it works although I can't say I've ever used it for anything and I'm surprised it doesn't cause weirdness in a lot of games. So does the A8 also do this with sprites? If so will it still be usable eg are there enough sprites, depends how you use them I suppose, and I can see there being some problems with which parts of the background are transparent depending on what weirdness is being used to get more colours. Also if sprites are used for more colours then you're stuffed there as well. I think theres pleeeenty of cpu free to just do a softsprite routine. The only difference is instead of dumping data from a foreground object into a mask you're just checking that mask to see if you should be dumping data into a sprite. Swings and roundabouts really.

Been a very long time for me too lol I can barely remember the C64 hardware registers. I can see what you're saying now (I think). Use a high priority sprite (say the last one), fill that with a hires mask, shove it behind the background and because its higher priority than the foreground sprites it will mask them? If that is what you mean then I'm pretty sure it doesn't work that way. The hardware draws the sprite thats been put in the background before the foreground and before the other sprites. It totally ignores it once it's been drawn so it wont effect the foreground sprites at all. I've just done a quick bit of code, 2 sprites, 1st one all FF 2nd 00 then FF, set them overlapping each other, filled the screen with C0 (dunno why I picked that but it's a reasonably solid character) then set the 2nd sprites priority to behind the background and that's where it goes, behind the background and behind the other sprite. All of that is with hires stuff. Not sure if it makes a difference if the background is MC or not.

@José I'll have to download that level editor. If all the stuff is there and can be loaded into an editor written specifically for the A8 then we're half way there. I've just been looking at VB.Net coding and it looks pretty simple to set up something that we could use to draw maps, add splits for colours etc (all the stuff I mentioned in my earlier post). I think if the maps are changed slightly from the c64 (who says that tree HAS to be there) then something very good looking with plenty of colour could be produced. Sprites, either way you've got to do some masking in software so it depends on if there are enough sprites to do that "beneath the background for extra colour" technique (I'll learn all your terms for all this stuff soon I promise lol) and to have 2 players + extra things on screen or is it simpler to do them as software sprites and maybe be lacking a bit of colour. It's something that could be decided at any time, either method would work, both methods are quite similar to code and both methods have their downfalls which might need some extra thought to work around. Pete

I'm not sure how they do it currently on c64 but I don't think there would be enough sprites on A8 to do it by copying a mask from the background data into a sprite. Also then what colour will it be? you can't overlay a sprite over another one to mask it unless its got data in it and even on the C64 you're limited to colours per sprite (1 background, 1 unique and 2 the same over all sprites) so your sprites would have to have the same colours as the background. I'm actually a bit confused about your explanation of putting sprites behind the background and them masking the foreground and err you lost me C64 you can set the sprite priority to either foreground or background but even in background mode they still show through pixels with the high bit of the colour index nibble cleared. ie colours 0 and 1 sprites appear over, 2 and 3 they appear behind. It can be useful, it can be a right pain in the arse.

Having read through this thread, because it's another game I'd like to see ported to A8 because I think it can be, here are my thoughts (that's if anyone is interested lol) First thing someone needs to do is write a level editor. Take a look at the c64 version, put it on an emulator (maybe output a video) and watch it draw the screen. What is needed are all those objects as separate entities. The rocks, the trees, the whatever else. This not only saves ram (you only need 1 copy of each object in ram and a map for them) but also allows you to mess around with them in the editor. I can see it working quite easily by using that method of putting player sprites under the screen to get more colours and also splits on select lines to get even more colour from the normal 4/5. Once again the editor can be used to do clever stuff like set a flag for each object being drawn to the screen to say if its 2bpp pixels need to be changed in any way. That means you can have an object with its normal bit patterns of 00,01,10,11 and say switch the middle two (it will probably be necessary that this can happen depending on how the colours are currently being used in that area of the map). Also these objects, whilst being built onto the screen create the mask map for any kind of spriting to be done, either software or hardware. Depending on ram you can either go the bpp or nibble per pixel (I don't think there are more than 16 depths of objects) equaling about 16k for a mask, eek! or a more complex method which is kind of too hard for me to explain here but is based on building a character map of strips of the screen and that character map is either, nothing there, whole 4x8 masked or "other" which would be an index to a proper 4x8 mask for that area of screen. The actual drawing/masking of 2 software sprites of the size needed (and any other things like when that dragon or whatever it is pops out the cave) should be easily doable with the A8's cpu. All in all I see it as being very possible to do but the grunt work is going to be in writing an editor to make the screens the same way the c64 does (and allow for that extra trickery to get more colours). There really is no use taking screengrabs of the c64 version, running them through some app that does god knows what and spits out a pretty screen Anyone experienced in writing "tools" and is interested, drop me a PM and I'll try to explain better. Unfortunately I'm rubbish with windows coding but if I have time I might try to knock something up, just don't hold your breath. I just hope my thoughts are useful to someone. Pete