[OT] Which IDE / Editor do you use?

[Manu]

On 20 September 2013 11:02, Nick Sabalausky <
SeeWebsiteToContactMe at semitwist.com> wrote:

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

That it was. I'm still amazed someone actually thought it was a viable
games platform, and even more amazed that so many developers made games for
it!
Fancy only having a couple of hundred cycles in the vblank, and just a
couple more cycles each hblank to perform 'game logic' ;)

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

Nearly all systems from that era had pixel-perfect collision handled by the
rendering hardware in more or less the same way.
Anything with separates fields (tilemap vs sprites, sprite vs sprite) could
easily latch a bit when an intersection occurred.

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

The SMS was an awesome little piece of hardware... perhaps my favourite
vintage platform :)
The took the popular TMS9918 video chip (used in colecovision, sg-1000,
msx, and a bunch others), and with just a couple of minor tweaks made the
system WAY better than any of the others listed.
All they did was added a few bytes for a user-specified clut (rather than a
hard-coded colour table), made use of an unused bit in the tile gfx table
to select between a second clut (doubling the number of available colours),
and added a horizontal+vertical scroll register for the tilemap.
The difference this made in practise was huge, and it's barely any more
gates in the chip. I always wondered why TMS stopped so short of the mark...
I suppose adding a user-defined clut is more than 16 bytes though. Fixed
clut will just switch between some hard-wired resister circuits, a
user-clut requires some more video output circuitry, but resisters are
cheap... even back then.

> 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 ;))
>

Aye to that; I had a lot of problems with the gnd circuit on vintage
hardware. They were very poorly isolated, and the gnd circuit would often
feed-back through all manner of surprising places.
A capacitor will smooth it off a bit, maybe protect you against some
suddenly flipping bits, or at least delay it until after a bit value
sampling tick has happened.
Considering how tricky that stuff is in practise, I'd like to know more how
it extends to modern circuitry. surely modern hardware must be better
isolated...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130920/e238012d/attachment-0001.html>