[tom_]

Is this really going to be true? Aside from the 6502, the overlap between the supported systems is approximately 0! I'd expect creating a cross-platform product to be no easier than it would be when working in assembly language.

[ddingus]

There are a set of basics, given some tradeoffs are baked in.

On most machines, one can get a bitmap. Addressing varies, but the rest makes sense. Give people a software blitter and that is portable.

Colors. Stick to the basics, that is portable ish.

Most machines can make a sound, display a character, bitmap, take keyboard in, etc...

Now, if one wants to see closer to peak performance, yeah. That is a labor of love at this point. Asm, hacks, the whole nine.

[vidarh]

Software blitting to a bitmap was too slow to be viable on most of the supported machines. Bitmap mode was only used for a very few games on the 8-bit versions of these due to how slow it was. On some of these you'd have to fake bitmap mode with custom character sets. E.g. the VIC-20 can at most give you around 160x160 pixels using redefined character sets. Conversely on the Amiga you have no other choice but to use bitmaps.

So just trying to blit in anything remotely portable manner would be a problem in itself. E.g. on the Amiga you can place things anywhere you want. On the C64 you'd place things on character boundaries (or take seconds to draw images, like a few adventure games that used bitmap mode did), and if you needed smoother movements you'd either smooth-scroll the entire screen or have two different versions of graphics, or use hardware sprites (even sometimes for background features).

If you want a common lowest denominator you pretty much end up with a mostly text-display (~22x23 characters unless you ditch the VIC-20), monochrome, unless you ditch the PETs, only beeps for sound, unless you ditch the PETs, 4-5KB total for code and assets (unless you ditch the VIC-20 and some of the PETs) and so on.

It might be a "fun" exercise for the sake of it to see what the best you could do in a portable manner, but it would really boil down to what the best you could do on one of the most memory-limited PETs is, I suspect.

I mean you certainly could do Infocom style text adventures... Small ones anyway.

If you cut it down to the NES, C64 and Amiga (and maybe Plust4), then you'd be able to start doing something somewhat more interesting, but the architectures are still so wildly different that you'd end up something unable to stretch the capabilities of any one of them. For slow-ish moving strategy dominated games it might work.

E.g. Sid Meier's Pirates! was partly written in BASIC on the C64, and while the Amiga port is an upgrade it's a small-ish upgrade (more colours, higher resolution mainly). That kind of game would be feasible to do portably if you exclude the VIC20's and PET's, and stick to C64-level graphics. Games like Defender of the Crown, likewise, though they'd lose the graphics quality on the Amiga that was 90% of the appeal of the Cinemaware titles on the Amiga (though ironically, Defender of the Crown is often considered better on the C64 (and some other platforms) - they fixed various parts of the strategy elements of the game).

[ddingus]

Actually, I have done software blitting on Apple 2, C64, Atari 8 bit.

That is the only way things got done on the Apple 2.

Look at this:

https://youtu.be/t7_hvzIaqxk

On an Apple 2, using both pages of bitmap memory, it was possible to move some objects reasonably back in the day with p code Pascal. Several of us did that in high school.

A compiled version, straight to ASM would do better. What I linked was the peak possible with hand coded blitters.

There is a low, middle ground that is useful. If one can include a library, written in ASM for each machine, more is possible.

Plus 4, C64, Atari 8 bit, Apple 2, Color Computer, and others all supported a 4 color bitmap, ranging from 128 to over 160 pixels.

Tons of games were written for those machines using software objects. NES does not quite fit here, though I suppose it could. I have not programmed it for a bitmap.

I think there is a wide range of expectations here. There is also groups of 8 bitters. Nothing but text is truly portable across them.

The basics I mentioned aren't AAA title grade. They can be fun grade, depending. And on the more capable 8 bit machines, possible.

Edit: you mentioned, stretch the capabilities. Yeah, I was not speaking to that at all.

Doing a stretch type work will pretty much take assembly language.

But, there are exceptions. Take a look at this Apple 2 project.

PLASMA is a high level, ish high code density environment, coupled with 6502 assembly. Perfect for big RPG games.

https://m.facebook.com/LawlessLegends/

Plasma itself is pretty interesting from an 8 bit development standpoint.

[vidarh]

You certainly can do it, but the point is you can't do it in a generic way across those platforms without ending up with something extremely limited to the point that if you want to do that, why bother targeting anything but e.g. VIC-20 or PET anyway? Because it will end up looking like a VIC-20 or PET program if you target it at the lowest common denominator.

Most of the listed machines run 6502's at too low speed to be able to move much graphics. It's not possible to do more than one write every ~8 pixels on a C64 if you want to actually write different values (you can demonstrate that easily by using a raster interrupt and repeatedly changing the background color as fast as you can) outside of lines where the vertical blank is enabled, for example. We did that a lot for demos - doing raster bands like that was a popular effect for a short while.

So you end up either limiting yourself to a handful of small objects, like Robotron; drop your effective framerate and accept glitches - like Robotron; or use custom code for each platform. Trying to do an efficient portable blit routine across those platforms is pointless. Compare C64 Robotron [1], which was considered outdated in terms of graphics by about 1983. It does not use bitmap graphics, but a combination of sprites and character graphics.

Which is back to the lowest common denominator issue: Sure, you can do software blitting, but you end up with something that wouldn't pass for a reasonable VIC-20 game even. Unless you exclude the PETs, you're stuck with monochrome; with the VIC-20 you're limited to 160x160 pixels, but even at only 160x160 pixels you're able to move just a fraction of those per frame. Then you have colour issues - even if you drop the PETs:

> Plus 4, C64, Atari 8 bit, Apple 2, Color Computer, and others all supported a 4 color bitmap, ranging from 128 to over 160 pixels.

Yes, so now you've excluded a bunch of the platforms on the supported list. If you do that, you can get somewhat more reasonable results. But you still end up with additional considerations, as the way they are stored in memory varies significantly. E.g. on the C64 a bitmap consists of a 2x 1000 byte block of 40x25 colour settings (screen ram and color ram as used in the character graphics modes) + 4000 bytes of 160x200 pixel values, which each byte representing 4x2 bit pixels, where for each pixel 00 = background and 01, 10 and 11 representing a nibble each from the 2x 40x25 blocks. This means that you can't blit anything beyond a 4 colour image to an arbitrary position - if it doesn't fall on a 4x8 character boundary, and you use more colors than that, you get ugly colour bleeds.

So now, now you're down to 4 colours or accept colour bleeds that would make anyone with a C64 draw derisive comparisons to a Spectrum, or you'll accept the need for a custom blit function. In which case, why the hell would you use bitmap graphics on the C64, when working within the constraints above makes a combination of character graphics and sprites far superior.

There's a reason why games were rewritten for each platform back in the day - it was less effort than trying to come up with some lowest common denominator that didn't just annoy everyone on every platform.

> Tons of games were written for those machines using software objects. NES does not quite fit here, though I suppose it could. I have not programmed it for a bitmap.

For the C64 at least it was very much the exception. It happened, for games with very static screens, though rarely even then, because it would have been an utterly idiotic thing to do for anything but mostly static graphics. In fact, you'll see a lot of later C64 games did do a lot of "blitting". Except they didn't blit pixels. They blitted whole characters, using the character mode. Afterburner and Barbarian II are good examples of this, that mix sprites with character mode. Last Ninja I'm not sure about - they spend a lot of time (seconds) "rendering" some of the screens, but I haven't looked at them closely enough to know if they did that using character blocks or bitmaps (there's clipping along 8x8/4x8 boundaries, but that might be a rendering artefact whether or not they use character mode; in either case they didn't use that for all the graphics - they also overlaid sprites on part of the screen as a poor mans z-buffering).

> I think there is a wide range of expectations here. There is also groups of 8 bitters. Nothing but text is truly portable across them.

Which was exactly my point. The lowest common denominator of the platforms listed on the linked page is ~21x21 characters in monochrome, with beeps for sound and ~4K RAM. You can technically get some semblance of bitmap graphics by using redefinable character sets on the ones that don't have a dedicated bitmap mode.

If you try to do something portable, the lowest common denominator is so exceedingly low that it's not very interesting.

If you want to go past that, you either ditch a number of the platforms, or you end up writing largely custom code for the graphics for most of them. Even between the VIC-20, C64 and Plus4, while you could reuse some code, it rarely paid off - you ended up not exploiting the capabilities of any one of them very well.

> Doing a stretch type work will pretty much take assembly language.

It's not even about assembly; even a hypothetical compiler that utilizes every available cycle will not abstract away the sheer differences of even something as basic as the memory layout of the graphics modes. And it's not about "stretch" beyond expectations of the very early 80's. Commando was not "stretch" in terms of C64 capabilities at all - it's pretty primitive [2] - it's just using character level scrolling and sprites. The music is not advanced for a C64 game (in terms of technically playing it; Rob Hubbards soundtrack is iconic, but that's a separate thing), but it's far beyond the abilities of e.g. a VIC-20 to reproduce faithfully. Commando level graphics would be pretty disappointing even on the C64 today, because later games did so much better. E.g. R-Type [3] style parallax is not achievable with bitmap graphics on a C64 - it depends heavily on being able to do bitmap scrolling of the definition of a tiny number of characters while scrolling the screen using the character mode. It combines that with sprites for most of the enemies, and character blocks for most (all?) projectiles. A 6502 at 1MHz simply does not have enough clock cycles to move that large parts of the bitmap every frame. But this level is "standard fare" on the C64 - those are the games we remember, because e.g. doing things like those parallax effects is cheap and easy, and so was all over the place at the height of the C64.

So it's that if you seek a lowest common denominator even excluding the PETs and VIC20, you end up with something that'd have seemed dated by about 1984, before most people with these machines got them.

I guess I don't see the point. I loved the C64, and I loved the Amiga, but I'd get no joy out of seeing C64 software that looked like it belonged on the VIC-20, or Amiga software that looked like it belonged on the C64.

[1] https://www.youtube.com/watch?v=oI05NfaNiAA

[2] https://www.youtube.com/watch?v=cdGaZ8Fakok

[3] https://www.youtube.com/watch?v=Bft5BhWIzTU

[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.