[ddingus]

Well, I share your love and agree on most of what you put here.

My only real point is a software blitter library would permit quite a bit, and be portable.

A secondary one was software objects got done quite a lot. C64 is actually one of the worst case scenarios. It had a considerable amount of DMA interrupting the CPU.

Apple 2 is a second worst case. No DMA, but addressing from hell.

The others, including the VIC 20, run faster and make a few more objects possible.

By all means, write for the CPU directly to get what those machines can do. I never implied otherwise.

But, if someone wants to explore a little, and wants to use C or Pascal, etc... more can be done than expected.

Re: Tearing

Yeah, the Apple port of Robotron does all those things, but is also one of the better ports. The action is there solid. So many ports did not actually deliver.

Atari 8 bit is pretty terrible. C64 looks nice, but just does not deliver the motion...

Sometimes it is about more than looking pretty.

[vidarh]

> My only real point is a software blitter library would permit quite a bit, and be portable.

But it really wouldn't be portable. Maybe you mean the software using it could be portable. Because you'd need to account for totally different memory layouts, totally different initialization, totally different movement rules if you want to avoid color bleeds, palettes ranging from monochrome and up etc. You'd likely end up with about as much code to try to make something like that generic as you would writing separate more optimized versions for each platform.

> A secondary one was software objects got done quite a lot. C64 is actually one of the worst case scenarios. It had a considerable amount of DMA interrupting the CPU.

It had some, but not very much. The 6510 didn't access memory other than every other cycle, so most of the time it ran unhindered. Some things would change this - e.g. it "cost" two clock cycles per raster line for every sprite that was present on that raster line.

It also cost you extra every 8th line when the VIC would need to retrieve new colour data from RAM, but if that was enough to tip things over the line you could "just" cut ~25 lines off the part of the screen you worked with and you'd have freed up more cycles than you lost. Some games certainly did "play games" with the display size, to cut the cost of graphics updates, but the vast majority of those games did that despite not even using bitmap mode.

The reason we didn't use bitmap mode was not DMA, but that character mode + sprites + raster effects was so much faster for most uses.

> But, if someone wants to explore a little, and wants to use C or Pascal, etc... more can be done than expected.

It's not the language per se that is the issue (though most modern languages are awful for 6502 platforms without lots of restrictions due to stack limitations); it is whether or not you write code custom for the specific graphic chips in particular for those architectures, which tends to make up a fairly substantial part of the overall game when you in most cases are looking at single to double digit number of KB including assets.

> Sometimes it is about more than looking pretty.

Yes, but my point is nobody would have accepted the C64 Robotron either already by ~1985. Game quality had moved on. By pure sales numbers alone, the majority of people who remember these platforms fondly today got them after the design of a game like Robotron was already outdated.

I just don't see the appeal of aiming for portability between platforms where what you do to achieve that portability completely eviscerates what people loved about that platform because the lowest common denominator is so far from what people were used to. In that case, just write for the VIC-20 or whatever matches your lowest common denominator directly.

[ddingus]

Yes, I do mean the software using it would be portable.

Consider it a display driver / primitive and call it good.

Old bitmap games have their charm.

Initially defines one or two pages, sets display registers, etc... done.

>movement rules

Blit needs two basics. One bit per pixel and two bits. That is it. Color maps and such do not need to be a part of things, or the programmer can manipulate them directly where they are available.

>whether write for gfx chips

Sure. Again, bitmap games have their charm. That is all. Trust me, I wrote to those chips and that is a different thing.

Your comment on the C64 Robotron is interesting. Had they broke a few rules, it could have delivered more like the Apple 2 did.

Players of Robotron would take it as the fast action trumps just about everything else. I linked that title as a great example, because of that.

I was there in 85, and plenty of us played the crap out of Robotron on the Apple and PC (given a fast enough one, lol) and played it because it delivered what Robotron was about. Many did not enjoy C64 or Atari Robotron because other trade offs were made. The arcade cabinet was common. The title was relevant.

The best ports rendered quick to a bitmap just like the original did. Now, the original had a 6809 and a blitter assist. That made for insane action, and is not directly comparable when considering minor artifacts along the way.

Here's the thing:

You and I both loved those platforms for similar reasons. No argument. Making something that can deliver across a more 8 bit machines does something else.

It does not take away from the greatness. When the demoscene gives up, I will worry. New C64 / Amiga productions still happen, and still push it all in that way we love.

But, there is a fun world of 8 bit gaming and such out there working differently too. Most of that is on a 1 or 2 bpp bitmap.

That is really all to the comment I made.

Recently, I have been enjoying things on Apple, Spectrum, and soon maybe a BBC Micro. Bitmaps and clever ways of delivering the goods. I found there are things to appreciate, I would have not before.

The more the merrier.

8 bits are enough. Honestly, that people still create in that space is a lot of fun. However they do that, I want them to do that.

Does not mean I would do it that way. But it does mean I would totally give what others did a go.

[vidarh]

> Blit needs two basics. One bit per pixel and two bits. That is it.

No, that's not it. You could parameterise a blit close to that easy on modern platforms with relatively uniform memory layout. Not on 8-bit home computers.

The Apple graphics modes as far as I understand stored 7 pixels per pair of adjacent bytes and the high bit shared across the pixels, to pick from an 8 colour palette with bleeding possible between pairs of pixels, while the C64 stores 4 pixels per byte, with each adjacent pair of bits representing one pixel.

The natural implementations of those two on a 6502 is completely different. And the bleed considerations for colours are completely different as well. But ignoring colour, unless the guts of this is written manually for each to minimize the umber of shifts and adds, you'll be blitting at maybe a tenth of optimal speed if you're lucky. To add the Amiga into the mix, since it's on the list of supported platforms.

But even for monochrome, different stride will mean a handwritten different version will mean a massive difference between platforms on a CPU like the 6502 that has no built in multiply.

You may call it a "driver", but really for a basic source to destination blit without any operations in between, handling the bit layout and stride is basically the entire blit function.

> Color maps and such do not need to be a part of things, or the programmer can manipulate them directly where they are available.

You can't do blits without taking into account the colour registers on the C64 unless you limit yourself to 4 colours (prefilling all the colour data with the same values), because they are affected by the position of the pixel. So either you drop down to four colours (including the background) instead of 16, or you can't ignore colour maps. Remember we're not talking palette settings her, but the per 4x8 pixel colour data.

So then you've basically decided to make something that will look totally inferior to anything anyone used to a C64 expects. That's fine. But if so, why bother targeting a C64? Nobody is going to say today "oh, this software only works on a VIC-20, what will I do?" - if they wan't to try it they'll just start a VIC-20 emulator - Commodore emulators like VICE supports most of the 8-bit Commodore machines anyway.

> Your comment on the C64 Robotron is interesting. Had they broke a few rules, it could have delivered more like the Apple 2 did.

They didn't need to "break any rules" - you can multiplex sprites or use character graphics to achieve far more very easily. That is part of the point: sticking to just the simplest means possible either looks ugly, or requires other tradeoffs, but if you actually use the capabilities of the platform you'd get something closer to R-Type than Robotron in terms of amount of dynamic elements and retain the gameplay. You don't need to even push the limits to get to something far better looking and playing than the C64 Robotron port on the C64. But you do need to actually make use of the capabilities of the platform. And bitmaps are not it.

> I was there in 85, and plenty of us played the crap out of Robotron on the Apple and PC

That may be a fine reason for targeting Robotron type games to Apple users used to that quality graphics, but both Apple and PC games were laughed at by C64 users at the time as ugly and primitive. It may well be that is a reason for our difference in perspective - to me there's little nostalgia with games that basic, as those were not the quality of games I remember spending time playing as a child.

> Recently, I have been enjoying things on Apple, Spectrum, and soon maybe a BBC Micro. Bitmaps and clever ways of delivering the goods. I found there are things to appreciate, I would have not before.

That's fine. But then I'd rather see something that actually takes advantage of the platform they're on and shows me something different, rather than something reduced to a lowest common denominator that doesn't show off what any of those platforms actually can do.

[ddingus]

I challenge anyone to write a sprite multiplexer capable of Robotron! Would be awesome to see. As for character mode, think through the cases. One arrives at a bitmap quickly, or the movement in the game isn't really up to snuff.

Neither of these are "easy" :D

The rule breaking are things like screen tearing, ignoring color clashes, using coarse motion where possible, etc...

>Color, differences...

At the software level, blit(x, y, etc...), the bitmap machines can handle one and two bits per pixel. Apple has color clash in it's high bit, C64 has it in the color cells, Spectrum has same.

That can largely be ignored.

>...Robotron type games to Apple users used to that quality graphics, but both Apple and PC games were laughed at by C64 users at the time as ugly and primitive.

No they weren't. We played the beautiful ones too. You are mapping your preferences on to all of this. Nothing wrong with any of that. It's nostalgia. We all are going to do it.

I am doing the same, and that's precisely why I said what I said. Bitmap games are a lot of fun, have a distinct charm, and do some things that just don't map to the higher order capabilities in these machines we love and remember fondly.

>I would rather see...

Well, there is coding something you want to see. Standard answer there. And neither of us even have to, as that's being done right now.

These things can / will get done too. The more the merrier man.

Re: Show off

Well, the C64 bitmap addressing is interesting. It's quick for vertical drawing in a way the others, which generally use a linear address, sequential byte per line scheme. I think it would have some advantages for these kinds of projects. "show off" is an interesting term, yes?