(This thread was inspired by Chris Adams' thread.)

Allegro is great. Don't get me wrong. I was coding with it for years. Then I strayed to DirectX (way too hard) and OpenGL (easier but still too hard). Then I came back. Then I strayed to Ogre (supposed to be simple but it's far more complex than it needs to be) and Irrlicht. Then I came back. And now I've strayed once more. Where? Back to Irrlicht. This was partly inspired by a new editor they have out for it but I also forgot why I left Irrlicht in the first place. Maybe the memories of 2D games came flooding back but now I'll leave Allegro once more, even if I end up right back here a few months later.

So now I ask you guys: What did you use before? What are you working with now? And what may you try in the future? List all of the libraries (for example, I also now use Bass to play OGGs and MP3s and I've been looking into a good networking library with nothing straightforward enough yet.)

I started with mIRC (not exactly a lib, and I believe it's using GDI).

I've spent quite some time with allegro, starting a few game projects.

Now I'm planning to finally complete a game with the XNA framework (Windows + XBOX360).

But after that I'll probably go back to Allegro and OpenLayer for a platform independent multiplayer game.

I've tried HGE (Direct3D based), but didn't liked it. No UTF-8 support, and other features was missing compared to Allegro. But that was some time ago, don't know now.

I've also tried FMOD and also didn't liked it because of horrible module support. Didn't tried FMOD EX though.

Now I'm using BASS for sound and Allegro for all other things.

I've worked with other popular libs, namely DirectX, OpenGL, and SDL. I've also worked with no libs at all back in the DOS days

Allegro does what I need it to do with a minimum of fuss. That, and I'm comfortable with it.

Java API

The first C/C++ compiler I used was Turbo C++, so it used the Borland Graphics Library, which was horrible. Then I heard about libgrx when I got an internet connection through work, which was much better. Through libgrx, I learnt of DJGPP, through which I learnt of Allegro.

According to the date on the 100+ page print-out I made of the Allegro manual (my employers would have killed me if they knew I used their fancy laser printer for such a purpose), that was in 1998.

I've been using Allegro on and off ever since, and I doubt I'll switch to another library, as Allegro more than meets my needs (I don't program games, I just use Allegro as a graphics library when I need one for some reason).

If I ever develop an attention span long enough to attempt to write one of the games I have in my head, I'll probably look into OpenLayer. Don't anybody hold your breath though, I think the longest I've manged to maintain interest in a project over the last ten years is about two weeks. Usually if I don't finish writing a program in one sitting it never gets revisited.

Direct-Y.

Never heard of it? That doesn't surprise me since I was one of only three people to ever use it. Back when Windows 95 was still new, a friend of mine decided to mock Direct-X by making his own DOS graphics library called "Direct-Y", which would allow for fast, simple access to 320x200x256 graphics in Borland C/C++.

On my website, my game Space Fortress uses Direct-Y... modified slightly to fix some problems my friend never got around to fixing.

When I switched to Windows programming with Visual C++, I quickly began searching for a graphics library I could use. Allegro was the first one I tried and for 2D I've stuck with it ever since. I thus have over 7 years of experience in Allegro programming, though only recently have I actually tried learning more about its internal workings and how it's actually doing things.

For about 8 months about two years ago I tried to transition from 2D to 3D using the Truevision 3D SDK. It was a big jump for me not only because of the change from 2D to 3D but because to get the most out of it I also had to start using VisualBASIC, which up until then I had only used for very simple programs. When I realized that nothing I could come up with in 3D would take less than a year to make I decided to go back to 2D with Allegro.

3D can wait until I can hire people to do it for me.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

FMOD 3.75 did work great for me (although I don't use it anymore), it played my ImpulseTracker files perfectly. What were your problems?

I use Allegro mostly for hacks (MinorHack, XmasHack, maybe next SpeedHack) and for retro games. Because in this fields it's the best game library you can get.
I once wanted to make a cross-platform game, including the DOS platform -> Allegro was the best choice.
I wanted to make a game for the GP2X which has no FPU -> Allegro fixed point arithmetics
It also is one of the few, if not the only open-source libraries that have a gift-ware licence. This is worth a lot in some cases.

On the other hand, when it comes to high-tech things, like 3D or surround sound, Allegro is pretty useless.
I currently play around with OpenGL and OpenAL. I use SDL for input because it's smaller and it has an event-based input system.

Don't remember correctly, but there was some problems when playing looped tracks (some backward jumps in orders/patterns, or something, don't know). FMOD played them forever and there wasn't option to make it play only once. Also there were problems with calculating length of such tracks. But this was some time ago and probably it's now fixed. I've switched to BASS and I'm very happy with it (especially the .mo3 files support).

I have been using Allegro since version 3.12, and stuck with it when I had the choice. For university projects, I came in touch with several other libs, none of which I liked enough to substitute Allegro with.

Nowadays, I'm using a colorful mixture: Allegro, OpenLayer, FMOD, zlib, Boost, guichan, ...

Well, I've been a bit into using OpenLayer for the acceleration. But I haven't had time for doing something serious with it.
In school we used Ogre for a ten week project and it went rather well despite its awkward points.
Currently I'm in a project where we do most things with OpenGL and windows api.

Right...

My very first programming contact was ZX Spectrum BASIC. I didn't get to use it much, because it wasn't my computer. I got first an Acorn Electron (with BBC BASIC) and later a SAM Coupé (with it's own BASIC that is quite similar to Spectrum BASIC). Thankfully none of these computers are useless C64 style rubbish, so they all had useful graphics commands and capabilities from BASIC. The first game I remember writing was a simple up the screen scroller where you as a car made from maybe the letter T drove up a track demarked by asterisks. I also definitely did a version of the tron bikes type game. My first "major" programming project was actually a Word Processor — my most 'impressive' achievement being that it supported reading and writing of ordinary ASCII documents. But I was only about 12, so give me a break!

We got a 486 PC in about 1993 or 1994 and the first gamelike stuff I produced was in QBASIC. Which I thought was thoroughly rubbish and have no nostalgia for whatsoever. I list my final QBASIC project (a parallel projected 3d thing) as 1995/6 on my website, I'd be surprised if it was actually that late. It's horrid, but thankfully the sources survive! In fact 95% of the projects I'm going to mention from here on in survive on my members.allegro.cc website or elsewhere.

After that I switched to Turbo C++ & BGI, of which I think I share LennyLen's opinion. It's really meant for business apps, and has a nice API for that purpose, but is slow as heck. But I learnt it all — not very well — from the online docs, so probably missed a lot of stuff. In particular I remember it being a revelation when I found out that if you set the border colour then you get a vsync for free, which made all my graphics much nicer from then on. Although in retrospect there is probably a vsync call that I just never found. My main Turbo C++ app was a forward port of my 3d thing from QBASIC. Lost is a 3d breakout clone I made with most of the same code. I also did millions of 3d graphics experiments because this is before I really had access to the 'net and I was just making all this stuff up myself.

Anyway, I never really got the weirdo DOS memory models so when I heard that DJGPP didn't have them I switched. Having a shiny new P200 was also a factor so we're probably in circa 1996. Initially I rolled my own Mode 13h but some of the "algorithms" I invented for it were horrid. I wrote a line drawer (fixed point DDA) then implemented a triangle filler by using the line drawer to get pixel locations along one edge of the triangle, and then drew lines from the opposing vertex to each. Incredibly slow! I had figured out perspective projections in the meantime though.

In late 1996 I joined the Allegro fray and, ignoring the Allegro software 3d even after it had eventually been added, improved my own stuff. I eventually ended up with my own polygon fillers for gouroud/perspective texture/constant-z perspective (so it'd do a perspective step along edges, then a linear fill either horizontally or vertically — very Doomish but without the trig optimisations you can make to the stepping if you assume a horizontal or vertical face) and so on.

Anyway, I more or less stuck with Allegro through to about 2000. I got some sort of trial version of MSVC 5 (same as the full version, but you can't disable a startup dialogue that says you used a trial copy) and knocked up a Deatchase 3d game in Win32 API and OpenGL. I'd had a 3dfx Voodoo for a while and had tried Glide/LCC and another otherwise forgotten library called (I think) Red X, but the toolchain never quite clicked somehow. A guy called David Raven sent me a free copy of the complete MSVC 5 just because he liked the game, and I'd moved into the realm of Windows.

2000 is also the year I began my emulator, ElectrEm. I'd done about 1,000,000 emulators before but ElectrEm was a smart move because the machine it emulates, the Electron, was reasonably popular and until then not properly emulated by anyone. The emulator got a following and I still update it.

It's while developing the emulator that I really started to stray from Allegro. At the end of its first implementation cycle it could be built with Allegro, DirectX, SVGALib, GGI or SDL. It then had builds for DOS, Windows and Linux. I used Allegro for the DOS port, DirectX for the Windows port, and any of the others for Linux as you saw fit to build.

In 2003 I essentially forced a break in code development and started again for SDL only as it had very quickly become my favourite of the many because it has a quite perfect combination of lightness versus features in my opinion, and I like it's essentially modular design.

Since then I've done most of my development on SDL. It's what all my personal library code works with, principally in OpenGL mode (though the emulator is just using it for a framebuffer).

My last two "significant" projects with Allegro were my part of what was then "the new Allegro demo game" and is now almost invisible and the 2005 ChristmasHack. My last significant contribution to the Allegro community was my small part in improving the DirectX acceleration for the current release in whatever capacity the changelog records.

Also along the way I recall trying or using Prometheus True Colour and an old software 3d thing called Plush. So, a complete list of game related APIs I currently recall using, BASICs excluded:

Allegro, SDL, GGI, SVGALib, PTC, Plush, DirectX, Borland Graphics Interface, Glide, Red X, DUMB

As I said, a lot of what I've attempted over the years is archived at my members.allegro.cc site. I'm currently working on an archive of old ElectrEm releases but have some gigantic holes. Not that I imagine anyone else is interested much! And I'm sure I've forgotten a lot from this mini-history of mine.

My first library on the PC was OpenGL, followed by SDL. I then came across a few games using Allegro, and gave it a shot about 6 months ago. I've found it easier to use than SDL, and I'm quite happy sticking with this for the next couple of games I have in mind.

I've used FMOD for my OpenGL and SDL games, no real problems.

Before Allegro? I wrote my own stuff. And then I realized I didn't have to because it was already made for me

Now, I use a mix of Allegro+AllegroGL for all my graphic apps. It's just not worth spending time rewriting window creation and event management code.

If I don't use graphics for my app, I usually skip Allegro and write my own things Chances are those apps either don't need to be portable, don't use any other Allegro features, or Allegro is far too heavy-weight for them.

Hand-written assembler code to directly call VESA functions.

Allegro.

Allegro 5.
I have no concrete plans to use anything else at some point; it's a hobby after all.

It was added to the svn tree a while back, but it somehow didn't end up replacing the old demo in the release. Don't worry, this will be rectified at some point! I personally thought it was a very nice game (though I sucked badly at it).

If there was, it's not mentioned in the manual either. I still have it after all these years (I use it as a C++ reference even though it's antiquated). I just looked through the section on "Video Functions" and it's not there.

Shortly after starting C++ coding, I found Allegro, and have yet to change.

Java
Game Maker (version 4 and 5)
Visual Basic 6 with the DirectX 7 (later, 8) bindings
C++ and Allegro, then later, AllegroGL

Now: C# with the Tao Framework of wrappers for GLFW, OpenAL and OpenGL (works in .NET and Mono)

I started with mode 0x13 in dos( 320x200x8 ). Then I attempted to use the anivga library for pascal but honestly I didnt understand a lick of it. And I still don't really. 4 planes for colors.. wtf?

Then I think my brother introduced me to Allegro so I moved from pascal to C and have been using Allegro ever since.

I started with QBasic, first doing only text things, then using the builtin VGA code, and then using the Blast library for Mode-X and high memory access. When I learned C I picked up Allegro, and right now I'm using pure OpenGL, though we also used Ogre for a recent school project.

I had a Sinclair ZX81 and then a Spectrum first, but I was very young and can't remember if I did anything more than type in listings from magazines. It wasn't until I was about 9 that I got an Atari800XL with disk-drive, 64k of memory and Basic! This was a whole new world and I did several unfinished games on the machine, but 3 utilities actually stand out.

I first did a Video Library program for my dad in Basic. The atari had a clever mode you could put it in where you could enable the text parsing from the screen and code generation while running. In practice this meant I could change the text colour to the background, clear the screen, then print to the screen a whole new set of data statements, scan them in to the program and then resave the program. This self-modifying code stopped me having to use a separate data file. I sent the program into a popular hobbyist atari magazine at the time 'page 6' (an area of memory) and it got a mention.

I then did a sector editor that could read and write sectors from a floppy disk. But because I didn't understand (or like) hexidecimal, I invented a whole new system with more letters to display the code in some kind of pseudo base 10 (as well as a character display on the right).

Finally, I remember doing a disk catalog program for my dad. This was pretty advanced as you could put in a disk and it would scan various sectors and work out whether the files were stored in a normal DOS 8.3 format, a Rob C menu or a multiboot menu. It would then read the file information from the sectors directly and add the programs on the disk to the main database after sorting alphabetically. There were also search functions and stuff like that. I don't think the program was ever passed on, but it would have been useful for other people who had many disks of games like we did.

Moving on to the ST was both good and bad. Good because it had a higher resolution, faster processor and GFA Basic was quite good. Bad, because unlike the Atari the ST had no custom chips to do cool things with, so effects such as hardware smooth scrolling were not possible. I missed being able to do cool things like that.

Then I moved onto the Amiga with Amos (and briefly BlitzBasic) and that was much better. I don't think Amos was that well optimised, but it let you use hardware scrolling, sprites and sound samples and I made a few things on there including my Dungeons game which got featured in an Amiga Magazine (Amiga Format?).

Moving onto the PC, even with a low end machine was like a whole new world and I found Allegro and DJGPP a bit by accident, but was soon making my bomberman game Dynamite even though I had no proper internet connection and no idea about C. I followed the code examples I had and so I had no proper idea of pointers, structures and defines. Ouch!

Since then, I've got better at C and moved onto limited C++, OpenLayer and using pure OpenGL. I am sure I will use many other libraries in the future. But I will always be fond of Allegro.

Nothing.

Allegro for graphics.
ZoidCom for networking.

For personal use, probably just Allegro.
For professional use, Torque with XNA, Direct X, Open GL.

Really, I know all the fundamentals of 3D programming and the general structure of using both Direct X and Open GL. (clueless about XNA except for the fact that we're learning it next semester...) But I don't see it as useful unless I had a group of people, not just myself. You see, I'm an OCD modeller and texturer, so to do anything in 3D would take a ton of art time and not something that I would prefer to subject myself to.

My little 2D exploits are just fine for a creative outlet right now. Anything that has to be 3D, I just draw and/or write about for future projects.

Nowadays, I use Allegro as a sort of glue and the lowest common denominator for my projects.

Basically, Allegro is a monolithic library that provides me with everything I might need for making a game. However, I might not be able to make the game I want using solely Allegro. When I need better GFX capabilities, I use my own OpenGL framework. When I need to handle sound better, I can use something built on top of FMOD. When I need input from two mice at once, I have to code for DirectInput directly. However, if I don't need complicated stuff for a given project, I can use the appropriate Allegro module and don't have to worry about dependencies, new APIs etc.

There is less and less Allegro in my Allegro projects as of late, but I still use it at least for de/initialization and input.

For various reasons, early computer hardware used bitplanes instead of grouping all the bits for a particular colour together. Although this can be awkward for drawing multi-coloured sprites, you can mix overlapping colours at no additional cost. That way, I managed to implement Video Games 1 on the Atari ST (the PC version simulates this effect by OR'ing the pixel-values together).

Ah yes. I had one of those as well. I definitely also remember a lot of the things you mentioned in your post. I cut my programming teeth on Atari Basic. Even managed to create a graphics mode with was a GTIA mode with a regular text-window (I used a DLI for that even though it was more of a modification of someone else's code than my own).

After that, got myself an Atari ST. Started with the supplied ST Basic but quickly moved onto GfA Basic, and then STOS Basic. I upgraded my ST to an STE two years later.

Several years later, I graduated from university (where I used all sorts of languages) and got myself a PC. This is where I discovered Allegro. At first, my Allegro programs were a mixture of C and 80x86 assembly, but nowardays, are mostly C (although sometimes C++ too). I still use Allegro for my hobbyist programming and even make contributions to the library.

Professionally, I've mostly used C++ and have worked with Dive (a fork of Renderware), the 3DSMAX SDK, and various other in-house bits and bobs. I also used the Mophun library when I got involved with the mobile-phone games bandwagon.

For a collection of games I've done over the years, see http://software.wackonet.net/ and get your emulators out.

AE.

Kazzmir: Planar systems were more flexible and in many situations faster. These were used before 256 colour modes were common, and give you the advantage of drawing 4 colour sprites like bullets, explosions and other such sprites nearly twice as fast as drawing a 16 colour one.

Andrei: Ah yes, GTIA! If only they'd done more with it. Like the STE and Amiga 1200 it didn't really have enough capabilities really. I wish they'd had a couple of new pixel and character based gfx modes with either higher memory requirements for more colours, or some kind of spectrum / BBC block attribute system to get 8 or more colours. That could have made a big difference..

Richard and Andrei: do you remember (if you heard of it) the book called "All the way with GTIA?" My parents bought me a copy of it, but I never really used it as I bought an ST a month or so later.

Isn't the GTIA the one that builds on the raster surfing of the 2600, but automates much more of it, letting you create a little display list that means the chip can introduce mode and video address discontinuities at predictable locations all alone? I always thought that sounded like the way 8bit consoles should have been done, albeit with more pixels!

The GTIA added several extended gfx modes (including some 16 colour ones at 80 x 224). It was only available on the XL and XE series of machines IIRC.

I don't think the GTIA was responsible for DLI (Display List Interupts), I think they were in the earlier CTIA chip too.

RpgMaker 95/2k (2000)
HTML & Javascript (2001)
Basic {i don't remember which flavour} (2001)
Python (2002)
Pygame {SDL for Python} (2003)
C\C++ + Allegro (2004)!
PHP (2005)
Java {forced by university courses...} (2006)

I started with QBasic and bombed royally; I could make simple text games and still graphics but animated sprites were impossible for me. Took up C++ with an interest in making it a career, ended my education not feeling much smarter. We used Visual C++ and played with MFC a lot, so I went looking for something a bit more "bare" C++ which ended up being DJGPP. The download page mentioned Allegro, I thought "cool" and downloaded that too. Rest is history. Since then I've also picked up Win32, OpenGL, some Java .. Allegro is simple video game easy mode though.

You mean it doesn't have the sound, keyboard etc. built in right?

My first graphic attempts were with some shareware assembler, and I had to buy a shareware disk called Fingerpaint with Hercules monochrome mode to find out how to do a mode set.

I used Recreational Softwre Design's Game Maker (don't think this has anything to do with the current one) for a while and made several platform and overhead games ~1995. Meanwhile I was learning C and programming text-based games (compiled using Turbo C++ 3.0). I had a book called VGA Game Programming Explorer which came with a disk with C code on it to handle various things related to programming VGA games.

I didn't know at the time that the code from the book would compile with my Turbo C++ compiler because I thought TC++ would only compile C++ code. When studying C I learned that C was compatible with C++ and figured out how to compile some of the code that came with the book. I started hacking around with the example programs and learning how to make the code do what I wanted.

My first C games used VGA Game Programming Explorer code for the graphics and MikMod for the music/sound engine. My first year of college I decided to give up all my pirated software so I deleted my TC++ compiler and wouldn't do any more games except experimental stuff with Ada which I was learning in one of my classes. The graphics library sucked for Ada so I went looking for a better one to use with Ada and stumbled upon Allegro and DJGPP. DJGPP intrigued me as it was a complete compiler for free, 32-bit, gave me access to a lot more RAM than TC++ did.

So I downloaded DJGPP and Allegro and started immediately making use of the new tools. Allegro was so easy that I was up and running in no time. I converted one of my old Turbo C games to use Allegro in an hour or two and Light Breaker 32 was born. I began work on a tilemapping engine almost right away but I wouldn't make anything with that for another year or two. I was actually working on a suite of game-making tools in the vein of the old Game Maker that I had used before so both me and my older brother could make some games together. These never came to completion. Later, I ended up using the tilemapping engine to make Paintball Party.

When I first started using DJGPP it was MikMod still for music and when Allegro became cross-platform I used FMOD in Windows and MikMod in DOS. I dropped DOS support partway through the development of Paintball Party so I used FMOD exclusively for a while. When DUMB came out I switched to that and have stuck with it ever since. I also added support for MP3 and OGG music to Paintball Party after a while and used AlMP3 and AlOgg respectively for those.

When OpenLayer came out I started playing around with that. I made a more advanced tilemapping engine taking advantage of hardware accelerated features. I had one game in the works using OpenLayer but I kept running into problems with it. When 2.0 came out I was excited but the excitement quickly faded as 2.0 was more broken than the first one. Many of the things that were broken have been fixed but I still can't get it to compile properly with the options I want.

To sum up:

• 1995: Game Maker (Recreational Software Design)

• 1995: Turbo C++ with VGA Game Programming Explorer and MikMod

• 1998: Ada and it's crappy graphics lib (never made any games with it)

• 1999: DJGPP with Allegro and MikMod

• 2000: MinGW with Allegro and FMOD

• 2002: DUMB and AlMP3 and AlOGG

• 2006: OpenLayer

• 2006: Back to plain Allegro + DUMB + AlMP3 and AlOgg where needed

The Atari 8-bits had two graphics chips - the ANTIC and the GTIA. The Antic was responsible for converting video memory into bitmap-data(such as rasterising fonts). It used a display-list in order to interpret each line of video-memory (eg. which graphics-mode to use per line). It sort of acted like a co-processor. Another thing it could do was get it to fire off an interrupt whenever a line had finished drawing (Horizontal blank). This was known as a display-list interrupt (DLI), and could do things like change the colour-register.

The GTIA chip converted bitmap-data into a video-signal. Depending on the mode, it would chose howmany bits make up a pixel (up to two). The two bits-per-pixel was a limitation of the earlier CTIA chip (used in early models of the Atari 400/800). The GTIA chip used a hack to get 4 bit-per-pixel colours. From the Antic's point of view, the 16 colour-modes were the same as the regular modes - it's just that the GTIA could be set to a mode where it interpreted them differently. However, this made high-resolution text illegible (unless a DLI was used to change the GTIA-mode). The GTIA also used the colour-registers to map a set of bits to a colour-value. It was also responsible for the sprites (player-missile graphics).

The Atari 8-bits had plenty of tricks up their sleeve. It was possible to create an 80x96 mode that could display all 256 colours at once. They could even do animated fonts with virtually no CPU overhead (changing the location of the font-data once per vertical-blank). Sadly in the days of 32-bit high-resolution display-devices that can be manipulated by the CPU in realtime, graphics programming has lost it's magic.

AE.

I disagree. I think it lost its magic for a long time, and then they invented pixel shaders! Sure the magic is more about maths now than engineering, but it's still magical.

I still enjoy playing with cool graphical effects and routines more than anything else. All my games (apart from Dynamite) feature some special graphical tricks or cool effects.

I think the magic has now shifted more towards the software side of things. But i agree that pixel-shaders are cool, but the magic isn't so easy to spot as the effects you could do on the old 8-bit hardware.

AE.

I don't understand why people think it's more noble or more "magical" to work under abhorrent, limiting conditions that always lead to inferior results.

Restrictions can make you have a narrower (but clearer) game design or idea. And then there is the satisfaction of getting around a technical hurdle. Perhaps you just had to have been programming on those machines to appreciate it..

The magic is when what hitherto appeared to be the limit of capabilities is exceeded. Just like in real life. The magic is now largely gone in the graphics realm because the limits are too wide, too vague and ever changing.

And pray tell, what makes it impossible for you to exceed the current limits in the same way? All I hear is curmudgeons complaining that it's too hard to stretch the limits of modern hardware, and/or being sour about it being too easy to do now what they took considerable pains to do 10 years ago.

I don't think any of us here were complaining in a 'sour' way.. Maybe it's nostalgia as well, we grew up programming on 8 and 16 bit machines and it was a very different era. Some people here only grew up with the PC and it's not the same.

Well, it's not impossible, just mostly futile on the PCs.

In the earlier days of computing a given platform stayed on the market in an almost unchanged form for years at a time. This gave developers time to improve and research new, clever techniques. And this work actually had some use, because they could then market the product using those improved techniques.

These days, you can see these taking effect on the consoles, mostly. If you look at launch tiles and "last generation" titles for any given console, you will invariably find that the latter have much better graphics, despite running on the same hardware - so the magic is still there.

On the PCs however, pushing the limits of a specific line of GPUs has little sense, because by the time you perfect your optimizations, that line is already obsolete. This doesn't pay off in the long term, so it's usually not done.

For the hobby developer, there are also other concerns:

• The old-timer magical gfx tricks often used very specific quirks in a given piece of hardware. This is nigh impossible on PC, because you'd have to write custom code for every permutation of computer parts.

• Also, these days, the bar is set much, much higher if you want to push the limits. The knowledge needed to devise a cool trick on the C64 or Amiga was not that vast. If you want to do something really great now, you have to have a very good grasp of mathematics, and the hardware itself is much more complicated. Therefore, the "magic" is less accessible to a hobby programmer.

I'm not saying that programming lost its magic on new hardware. But it's definitely a different type of magic now, and not all of that difference (but surely some of it) stems from nostalgia.

I remember feeling peeved about all the electronic music stuff etc. coming out 20 years ago, I felt like I'd wasted my time learning to play guitar. And I feel kind of sheepish about all my software rendering and FPU emulating code. It's not easy to admit you did something that turned out to be a dead end.

OTOH, I remember seeing those (pre-rendered) advertisments on TV for console games, I thought how my games would never look that good, now that you've all convinced me to use Open GL they do, but the current advertisements have raised the bar again.

[sarcasm]
Progress should be outlawed
[/sarcasm]

You set a graphics standard for your game once and then don't care about progress.
As a small developer you shouldn't try to compete on the eye candy side.
Focus on the things that make games popular for decades instead, gameplay.

I started with basic then DarkBasic but never made a full game. Then I moved to C++ and just wrote tons of text games( man I loved making those, good way to learn the basics too) for a few years. Found allegro somehow and I've been here ever since.

It's nostalgia for the experiences of the joy of getting it all to work. Also, even though the hardware has long since become obsolete, the experience I gained from programming for it was the foundation for experience that I gained later on.

AE.