andym00

Think it mixes and matches throughout.. Some aliens are chars, the high speed ones, other sprites.. But the players ship and the players multiples are sprites.. All the bullets are chars though.. Though it only ever plots "character sprites" over parts of the background where there's no level characters, so it can change the attributes to give them more colour.. Except in the explosions which it looks a bit dodgy on.. Salamander uses character for bosses, and then uses the sprites on top for things like the arms etc.. Look at 3.20 on the salamander video to see an example.. And other times swaps it around, the boss as sprites, with arms as characters.. See 5.10 for that way round..

C64 version is out of question, you cannot use anything of it! It's a totally disaster: Gfxs, Sprites,... all! You really think so José ? I thought it would have been a good start point.. One thing it does have in favour of what you want to do is that a lot of enemys are drawn in characters anyway.. Look right at the start (about 20seconds on this video) and they're not even software sprites, just character based object moving on character boundaries.. There's not a lot of hardware sprites in use on the 64 version at all.. Personally I think this is one game that would work quite well actually.. edit: And also, even with Salamander it's pretty much the same situation.. These are both games the A8 could pull of pretty succesfully if you ask me, but you didn't, so I'll shut up

Check the Blog out, I believe it uses a fairly complicated font cache system of generating preshifted characters, hence the 'all over the place' character useage.. Also on CSDB I recall that he discussed the actual sprite rendering method in some detail..

Keys, every day of the week.. Far more precise than those joystick contraptions obviously.. Duh

Oh yeah, of course char. mode.. Just wanted to put it forward as an example of the 2 Charsets and changing of colours per frame.. Which is what it does if I recall rightly..

I think this is what Crowther did in Phobia, on the C64, for a good idea of what it could look like.. http://www.lemon64.c....php%3Fid%3D763 Obviously the A8 will have far better results with its palette than the 64 though..

Yeah, burn me at the stake

if u had actually ever tried drawing a decent looking sprite in what is effectively 8 pixels in 2:1 aspect mode then you wouldnt ask that question. even the spectrum ones i did for armalyte were 20 pixels across in 1:1 aspect mode so they could be pre-shifted into 24 pixels AND keep definition. I'm a programmer, and there's a very good reason why I'm not an artist and that's because I have the pixel pushing ability of an quad-amputee Aardvark But those 8 pixels are in fact 9 though, since you get the extra one free if you're prepared to store shift-0 3 bytes wide instead of 2, but that aside, I did kind of lose track that this was about exactly copying Armalyte rather than anything else.. As TMR mentioned below, Xeo3 does look bloody good for such limits, and in honesty I find the smaller size a better fit for the screen size.. The C64 sprites at 24x21 always felt too big for the screen once the sprite was filled, and I think that's a common theme in many shooters on the 64..

Well best you stock up on your glycerine tablets then 22 is probably too much, *if* all the sprites are required to 24x21, but who said they had to be I've not looked at them closely, but aren't a lot of sprites not the full height anyway ? I'm guessing some blank lines at top and bottom to ease any multiplexer glitches since it was never a rocket-science multiplexer that one.. No offence to Liddon and his sort routine In all fairness, whenever I've thrown sprite numbers around I'm always thinking 16x16 and really don't get why people want to duplicate the 64s crap 21x21 sizes, apart from being able to nick-art at the expense of bloody expensive sprite routines Anyway, I'm sure most of the sprites are in fact 24x21 and I've just dug a deep hole for myself

Got a bit carried away, yeah

Mostly it has.. Haven't done proper crunch for donkeys years now, but there's a lot of get ready for E3

For me, don't want eor'd sprites, and don't want to pay anything (memory-wise) over the basic cost of the shifted sprites and masks, with those being compiled on the fly.. And for me char-mode more than pays for itself over bitmap mode when it comes to erasing the sprites.. And I don't special case the shifted y-position anymore simply because in 90% of the cases they're simple stores anyway without masking, and the cost of the additional copy, with far far less setup mitigated the cost of the extra writes and the few cases where it pointessly masks zero data in.. I've given up going to the absolute fastest sprite systems now, because whilst you can do a nice demo they're fecking useless for writing anything with.. And that one did the job for what I wanted and did it fast as well, with a lot of flexibility thrown in.. Horses for courses Just saying I think you could do Armalyte using that kind of system very easily.. But I guess I'll just have to put my money where my mouth is and make a side scrolly shooter test-bed, which'll probably result in José wetting his test-bed with excitement

Neither there is no screen layout in that sense.. The screen is broken vertically into zones and this can be different heights down the screen.. Each zone maintain a character that is free to use for sprites.. This can be different in each zone, depending upon how many character the backdrop needs.. In the code i posted it does assume <32 is the background graphics.. though a lookup table would allow a modifying branch to be used witha fixed arrangement for more free chars and actually a slight speedup and the implementation of the PoP masking i mentioned.. It just picks a character, if it's zero, allocates the next char in the zone, and copies the data in.. If it's non-zero and less than 32, it allocates a char and mask the sprite on.. if it's >32 it masks the sprite straight into the character, since it's been generated this frame.. Not the fastest as I said, but I find it pays off nicely and works well, and is very flexible.. So, no ABC order or ADG ordering Though in theory it will generate ABC ordering, kind of..

I didn't mean using PMs only, but with software sprites and PM underlays.. What I meant was one that's viable for game use, that doesn't trade massive of memory (either code-wise or graphics-wise) for performance.. For my Galaga & Galaga'88 hybrid stuff I eventually settled on a a nice system based on this method which works really well.. Performance is nice, not the fastest, but offers width and height flexibility without too much setup cost (in fact very low compared to some of the other techinques I played with).. restore cost is very fast using code stubs for each virtual sprite which self modifies, and also makes redundant moving around of variable quite low as well.. And a few other bonuses fell out of the system as well that I didn't expect.. Things like being able to mark regions of the character set as having a foreground mask, so it allows things like the PoP going behind pillars stuff for free, well okay, a few extra cycles per byte when it occurs, but no additional handling required.. And I can see a lot of uses for that in other things, cool things, nothing really practical I tried umpteen other character set attempts, and just settled on this as it seemed to be a nice balance, especially given in for what I want, and what Armalyte would want most of the chars aren't going ot be masked.. I still maintain that Armalyte is very doable with such a simple sprite methodolgy.. The PM multiplexor isn't an issue in this case Anyway, code dump straight from the last working code of this stuff.. Comments might be out of date, but you get the gist It's textbook stuff, nothing clever, just for what I wanted, with variable sizes gave me a nice tradeoff and would work simply with scrolling the screen as well, and a sprite core that only eats ~4K of code, when unrolled vertically.. I even binned the idea of treating the unused lines at the top and bottom of it specially since I just found it wasn't paying off enough when compared against the code size, so just used sprites arranged in column style with padding between and just masking/copying the zero data.. It made life simple, and didn't make that much difference when all thrown into a real situation.. Hell, there's even optimisations in this to be had, but as I said, it's from a testbed where I was playing with even more software sprite ideas, and in it state it was last left in.. !macro cs6_line .x, .width, .screen, .zone_char_base{ .do: ldy .x lda (.screen),y bne .not_empty ; Character is zero, just allocate and copy.. .empty: txa sta (.screen),y lda char_mul_8_lo,x sta Dest_Char+0 lda char_mul_8_hi,x clc adc .zone_char_base sta Dest_Char+1 inx ldy #0 lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y iny lda (data),y sta (Dest_Char),y jmp .next .not_empty: cmp #33 ; +1! bcs .no_alloc ; Copy base character into new and mask data onto it.. .mask tay lda char_mul_8_lo,y sta Src_Char+0 lda char_mul_8_hi,y clc adc .zone_char_base sta Src_Char+1 txa ldy .x sta (.screen),y lda char_mul_8_lo,x sta Dest_Char+0 lda char_mul_8_hi,x clc adc .zone_char_base sta Dest_Char+1 inx .mask_go: ldy #0 lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y iny lda (Src_Char),y and (mask),y ora (data),y sta (Dest_Char),y jmp .next ; Character is already a created one, so merge into it in place.. .no_alloc: ; This is special, because we modify the existing character in place.. ; And to reduce code size we share the normal mask code.. ; It would be faster to only use Src_Char, but it costs too much memory for the extra code bloat.. tay lda char_mul_8_lo,y sta Src_Char+0 sta Dest_Char+0 lda char_mul_8_hi,y clc adc .zone_char_base sta Src_Char+1 sta Dest_Char+1 jmp .mask_go .next lda data+0 ; We can set these up in advance.. The old each column seperate clc ; pointer since we can reduce the loading cost on each.. adc .height ; So that will save 9*lda abs per 3x3.. Also will save carry sta data+0 ; set cost as well.. sta mask+0 inc .x ldy .x cpy .width beq .exit jmp .do .exit } CS6_MEM_START = * lol, and no comes the signing away of my life.. If I find sometime I'll put something together with Armalyte'esque sprite counts just to prove the point And it's something I've been meaning to do for a while actually, and will make a change from bloody stupidly complex alien logic in my Galaga gubbins But in crunch mode for the next week and a bit, so don't expect anything before then..

On PAL at least I think you could pull off Armalyte almost pixel for pixel on the A8, in fact with probably a bit more useful colour added.. But the killer comes with NTSC which I just don't see how that'd be feasible.. Not at 60FPS anyway.. And not with the numbers I've seen coming out of my software sprites.. I really think you can do this (in PAL at least) with a fairly conventional character based sprite system and a nice PM multiplexer

Just thought I'd stick my nose in quickly because José is doing an ace job here again Just wanted to point out that from an implementation point of view that Armalyte actually only uses 6 sprites really.. The 2 sprites used for the player(s) space ships aren't split at all to avoid any flickering malarkey that might occur.. So only the 6 remaining sprites are used for the AI ships in the multiplexer, which means it's not beyond the realms you could do something fairly reasonably with a quite simple engine on the A8..

Is that the tackiest you could find? It was given the limited time span available to me

Will that do José ?

That was a good one. LMAO I'd forgotten about that quote from donkeys years ago Reminded me of this I saw the other day...

That solution gets my vote for getting more traffic through the 8bit programming forums..

Didn't think you were gone that long-- perhaps went to take a shower. Chewbacca fits in but straw-man didn't as I pointed out. Still don't know what either of those actually are supposed to mean, and to use the andym00 defence: ' I don't care'

I don't know if you're joking, but more than 5 colors/line w/o midline color changes is possible at 160+*200 resolution either by doing resolution enhancement from GTIA modes or GPRIOR mode 0. I was joking... some people tend to say use every feature available just for the sake of using it... even the artist does not want to use them... But Paradroid in APAC would be sooooo cool

Emkay, why not go learn to program, then all of these ideas you have you'll be able to turn into reality in minutes/hours flat.. Really, I'd like to see you try and turn some of these ideas into reality rather than just vanishing into the ether... That said, I'm not sure you're going to have an easy time of it with this.. Getting the SID notes and volumes is one thing, but you're going to spend as much time recreating patches and getting tripped up by the gating methods and waveform switching than you'd spend just manually transcribing the music by ear straight into RMT..