PeteD

Go take a look at the code and exactly how Karateka works then you'll be able to make an informed comment

Like I said above (or at least tried to), the chars needed for each "individual screen" will fit into a single 256 chars (which doesn't really help the A8). The reason it's bitmap on Mr SIDs version is he's chosen to reverse engineer the Apple version and use as much code and data as he can which has resulted in a screen that has tiles that are 63 pixels high so you end up with nothing being on char boundaries which would result in way too many unique chars if you don't just dump it all into a bitmap. Moving the graphics just that 1 pixel (and shifting a few things left or right) means you can fit everything nicely into the 256 chars. On the A8 you'd no doubt have to go for a new set of characters every X number of lines to allow for all that stuff and the soft spriting. Because of that you're already looking at more ram usage than the C64 so it's going to be an >64k machine OR a cart If people are happy with that conclusion then my explanation of the difficulties in the soft+hard sprite mix (post above somewhere) becomes somewhat moot because you can spend the extra RAM/cart space on allowing a compression method that handles the 2 parts separately. Doing that means you can come up with a less processor intensive decompression which means despite having to work on chars AND PMs the A8s extra bit of CPU grunt should take up the slack..

Hi, PeteD have just post asomething about Pop on FormatWar about our in the past talking and your '?' of how will I get the STE86 frames into A8. Now I just don't need any of those 'tricky' solutions Well from the work me and Ste did on C64 PoP I think it'll fit into 64k (with a bit of squeezing) and it uses char mode (variable amounts of chars as it builds a new charset for each screen by doing the painters algorithm drawing and checking for existing chars to reuse). The biggest problem on the A8 was and still is if you're mixing chars and PMs for drawing the guys it's a lot harder to a) compress them as you're kind of compressing two lots of stuff and b) draw/mask them with the background objects such as the columns they have to go behind. If they could all fit into PMs it would basically be the same as the C64.

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

Sorry, forgot to post "barring some demo type code that'll only work in very specific cases"

No theory needed, it's the same reason people have given when you've asked the same thing in previous threads and it's the same reason any game will tear not just C64. It's taking over a frame and not double buffering. Project M, I'm pretty sure, doesn't run in a frame either. If you double buffer and your're updating the whole screen every frame, rather than drawing changes from the previous frame (likely with wolf style games) most people sync to the VBI to avoid the tearing you'll still get switching buffers mid-screen which will slow the game even more (if you sync to VBI and your game only takes 2.2 frames to process it'll now take 3) but you don't need to do that, just switch when the scan is before or after where the updates are happening, the shorter the changing display area the more chance you've got to do that without wasting time. *edit* You're right about colour ram, it's the one thing that can't be double buffered on C64 so if your render requires it you've got to do it at the end as quickly as possible, with something like 3D you could create a double buffer for the info as everything else was being rendered but you'd still have to dump that to the video ram at some point.

And it shows tearing.... again. Which means , not all content of a frame is drawn within a frame. That's what double buffering is for..

As far as I can tell that music (Centric Preview) is running off timer and calls the routine twice per frame so it's 100hz update.

But, does it really depend on the SID 6581 chips themselves? Or is it a matter of choosing the right capacitors? Remember, the SID filter is a pair of external RC-circuits, IIRC. Me for example, I have the following 6581s (see picture below). Do these chips themselves have different filter effects? (by the way, sorry for off-topic stuff) I think it's pretty much down to R/C tolerance Nope As I said on the previous page, part of the filter is on the chip and while it's sometimes just manufacturing differences (they changed the silicon used over time etc) I think there was also some difference to the die design. The chips Analmux has for eg are seemingly all R3 apart from the single one labeled R4. You can tell by the dates (the 4 digit number is week/year) and the either 6581, 6581 R3 or 6581 CBM all mean R3. If it was as simple as matching the external components then people would be doing that and I don't think I've ever heard of that happening..

But, does it really depend on the SID 6581 chips themselves? Or is it a matter of choosing the right capacitors? Remember, the SID filter is a pair of external RC-circuits, IIRC. Me for example, I have the following 6581s (see picture below). Do these chips themselves have different filter effects? (by the way, sorry for off-topic stuff) It's the chips themselves. Part of the filter is on the chip and that's "helped" by the capacitors.

Even Avenger? Hence the "most" A lot of people never even find that one because they go searching for "space invaders". It's about the best I've seen so far but I think it still leaves room for a "proper" port. Pete

I believe, from my investigations, the trail is caused by something along the same lines as a bug I had in my own code All the sprites (apart from your ship) move 2 pixels at a time and (like mine) are placed in bytes in such a way that there's minimum 2 pixels at either side of them so when they're redrawn they actually auto-delete the data from their last copy (it's a bit more complex than that, bit of masking going on too) BUT the last enemy moves 2 pixels when it's moving left and 3 going right Supposedly it's to make it harder to lead it to get the shot and to confuse you into chasing it rather than just staying put. That would explain why it leaves data behind. I was going to redo my graphics so they were all capable of single pixel movement but now it seems if I don't I'll get the arcade perfect glitches too

I think is a vid of it? 3:30+ mins in. *edit* Sorry, Missed your edit James Pete

Cool, thanks I might do Deluxe later as my code should handle it. Got another arcade port and loads of other projects (haven't we all) on the go though.

There will be an option to turn them off I'd originally thought of putting something in that space then decided against it, I wanted it keep it pure, then Ste did them anyway and I think as an option it's nice. Pete

@JamesD, that FIRE bonus you mentioned earlier, is that in normal SI or just Deluxe? I can't find mention of it anywhere for SI but have seen it mentioned for Deluxe, but me not seeing it mentioned doesn't mean it doesn't happen Would be cool to include it if I can see what it's supposed to look like.

Sound is a big issue for me, I'm trying to find someone who can reproduce them as closely as possible. It's the firing noise for me, that's embedded in my brain Theres diagrams of the sound stuff over here Pete

I'm currently finishing off an SI clone for the C64 which could no doubt be easily ported to A8, so I might do that... It's done exactly the same way as the arcade, drawn into bitmap, invaders updated one at a time, has all the tricks (bullet counting for mothership 300 points etc) pixel perfect collisions, graphics straight out of the ROMs. I've spent a lot of time researching, going through frames of the game spat out of MAME as pngs (about 3000 of them until I sussed you could single frame advance and take screenshots lol) so all the speeds/timings/movement of everything is correct. I found things that I'd never really noticed before like when you hit an alien it actually pauses the whole wave movement routine for 16 frames. The main problem is afaik all the arcade machines are 60fps so on PAL the updating one per frame method seems a tad slow, I could always update 2 every 5th frame or something but I think it's ok as it is. I've added "decal" graphics (done by Ste of course) to fill in the spare bits of the screen (with the arcade only being 224 wide) and the score/lives are in the border to handle the screen being 260 tall. The "decal" also continues into the border to stop it looking a bit naff.. Hopefully be done by the end of the week as most of the remaining code is 1/2 done or just involves re-using existing code. Most of the C64 version suck so I'm hoping this one will go down quite well.. Pete

I was just about to say the same thing Sorry I didn't have time to help more but I went straight from one project to another and got kind of sidetracked It's all sounding great. Pete

Not given up, just got sidetracked with other stuff and working on the A8 suddenly became less interesting after I posted some WIP stuff last year I'm still planning on at least attempting Fist on A8 because I want to do other versions of it so once I've got all the anim tables, collision tables, ai etc coded for some platform the A8 version just becomes that same old nightmare of what Ste mentioned, not letting the whole thing splat like crazy. We've already got all the backgrounds worked out so displaying everything is possible but it WILL have some clash somewhere. Jacketing the Beeb version is done apart from fixing up the line offsets for the drawing, I think I posted a youtube vid of it some time last year? Looks horrible though in 4 colour which is why I haven't bothered to fix the drawing... It's like Last Ninja, that works from the Beeb too, draws wrong, not worth fixing cuz who wants blocky 4 colour LN!?

I thought you were dead?

The C64 is better than both of them!!!

*cough* Good save

You forgot the error checking. IF BOOBS > HANDFUL You don't want an overflow happening now, do you?

The question is, do you like your boobs big and heavy or small and fast?