[OT] Which IDE / Editor do you use?

[Nick Sabalausky]

On Thu, 19 Sep 2013 23:07:42 +1000
Manu <turkeyman at gmail.com> wrote:

> On 19 September 2013 17:24, Nick Sabalausky <
> SeeWebsiteToContactMe at semitwist.com> wrote:
> 
> > On Wed, 18 Sep 2013 13:31:48 -0700
> > "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> > >
> > > I remember in the old DOS days, some games would load up custom
> > > graphics into the video card's text font buffer, so that they can
> > > draw sprites just by writing the corresponding characters into the
> > > video card's text buffer.  You can get very fast drawing rates
> > > since the video card does most of the work for you (and you only
> > > need to transfer 1 byte per 8x8 block of pixels instead of 8
> > > bytes or more).
> > >
> >
> > That's essentially the same strategy behind the graphics hardware in
> > most 8/16-bit consoles. Basically the ones from around SMS/NES and
> > then up until 3D. You can identify them from the grid-based
> > layouts (which were a huge improvement, for both gamers *and*
> > developers over the "carefully time your opcodes to adjust the
> > scanlines while they're being drawn" used by Atari VCS/2600 and, I'm
> > guessing, probably the ColecoVision and SG-1000, which is what make
> > them so amazingly affordable at the time).
> >
> 
> Atari 2600 was the only scanline renderer I know of from that time,
> and it certainly was made to be cheap!

It's a genuinely impressive feat of minimalistic engineering. And it
makes Pitfall all the more impressive.

Several years ago, I made a little semi-game for it. It wasn't really a
true game - there was no objective or score or game over - just a
player character, a one-screen room with wall collision[1] and two
objects that made you change color when you touched them (and then
change back upon pressing the button. Heh, yea, "the" button on the
controller ;) ).

I even designed and built a (not particularly reliable, b/c I forgot
to account for signal propagation delays) EEPROM burner, bought a
2600-cart PCB with IC socket, and ran the "game" on actual hardware :)
Cool stuff.

[1] That's another fascinating thing about the VCS/2600: Unlike
many later systems (at least to my knowledge), it had *pixel-perfect*
collision detection *in hardware*, as a trivial result of the
playfield/sprite *rendering* hardware.


> ColecoVision and SG-x000 were not affordable by comparison to the
> 2600.
> 
> ColecoVision, Intellivision, Atari 5200, Atari 7800, NES, SMS
> (SG-1000 and friends), Genesis, Snes, C64, etc, etc were all tile
> renderers, and the first 5 items in that list didn't even have
> scroll-offset registers.
> 

Ahh, ok, I didn't know that about ColecoVision, SG-x000 or
Intellivision (or the later Ataris). I've never had much experience
with those ones  (even as just a player), so I was just guessing
based on what little I could remember of the graphics. I'm more familiar
with VCS/2600, NES, and to a lesser extent the SMS (beyond the SG-1000
era, so like Alex Kidd, Fantasy Zone, Phantasy Star, etc).

Come to think of it, I have played an SG-1000 game (involving a penguin
pushing an egg) that was very clearly tile-based. Actually looked very
CGA-like, come to think of it.


> In DOS, a lot of CGA/EGA/VGA games used a similar approach as
> > DOS-text-mode/NES/SMS/etc, but it had to be done in software.
> > Obviously in those cases it didn't reduce the amount of data sent to
> > the video card, but it did still reduce (significantly) the amount
> > of HDD and RAM required to store the levels, and it somewhat
> > simplified/reduced the amount of processing needed to render.
> >
> > (I've done a bit of old-school homebrew, and got my real coding
> > start in DOS VGA gaming. Fascinating and incredibly fun stuff to
> > develop for. I'd love to design/build my own tile-based console
> > someday, just for the heck of it.)
> >
> 
> Do it, it's surprisingly easy, but jolly good fun :)
> 

Yea, it really is surprisingly easy, and I definitely want to. If you
understand low-level bit-manipulation, then you really understand the
core of that you need to know. The rest is pretty easy to pick up if
you already have that basic knowledge, since that's all digital
hardware really is - bit manipulation and logic gates.

You just have to remember to take into account:

1. Signal propagation delay (Probably the main reason my EEPROM burner
failed about 67% of its full image transfers - there were brief
intermittent bit flips, like 0->1->0, when the logic was *supposed* to
keep an output bit the same)

and 2. Remember to stick a capacitor across the GND and +5v (or
whatever voltage) pins of each IC (Which *improved* my burner's success
rate *up to* 33% of full images written versus a paltry 33% of *bytes*
written ;))