The Dink Network

Reply to Re: Announcement: Dink Engine Source Code Release Imminent

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
July 12th 2003, 12:21 AM
wizardb.gif
jameson
Peasant He/Him
 
Nexis,

you make a number of very good points, but I'd like to comment on some of these as I do not fully agree with everything you have said.

30k lines of code in 3 files sounds horrible, but it doesn't have to be. Ideally, these files could be split into more rather straightforwardly, although I'll admit that this is probably unlikely.

I'm not sure whether your suggestion of porting dinkc to have a "proper" frontend makes sense; if the dinkc frontend works (I have never used it, so I can't comment on that) the only (albeit significant) gain here would be maintainability. But there are other clever ways for coding tokenisers and parsers (although these tend to be done in rather more powerful languages), so this may not be a problem yet.

When it comes to lex and yacc (or flex and bison, their GNU replacements), I should point out that these aren't anywhere as complicated as you make them sound-- they have a syntax of their own, that's true, but it's a simple one. The only issue here is that you will have to know what context-free and regular languages are , and how these are specified (i.e., what regular expressions and BNF grammar specifications are). Granted, without that background knowledge their (extensive) manuals may seem confusing at first glance. Reading up on the theory first, however, should clear a lot of things up.

Adding support for other graphics formats would probably be quite straightforward, given that there are existing libraries which take care of that. I agree that supporting more than one colour depth would be very useful, particularly for systems which don't allow randomly changing the active colour depths.

Requiring movie codecs to be shipped with games would be somewhat problematic with respect to portability-- some codecs are not widely available (only for Mac, or only for Windows, or whatever), and you wouldn't want people to ship executables for each platform the game could possibly be run on. If movie playback was to be supported, I would suggest either falling back to OS-provided mechanisms or standardising on one fixed codec.

A new dink should, at least initially (for purposes of porting and general backwards compatibility) be able to run all of the old stuff. When it comes to changing the dink file structure, it may be possible (I don't know, I'm not familiar with the current one) to use a more scalable format while still providing read-only support (for the actual dink interpreter) for older files. I don't see why you'd want to merge separate files, though-- the file system already provides a neat mechanism for storing separate pieces of information in separate chunks, so just using an off-the-shelf directory instead of a wad or RIFF file would seem like a much more transparent solution to me.

When it comes to porting, I agree that any port should be done in the same code base as used for future development. However, I would suggest first abstracting out (using templates with inline function calls, preprocessor macros or abstract classes where neccessary) all sound, graphics and basic I/O (file selection mechanisms etc.) stuff instead of hopping onto the SDL bandwagon. SDL does not give good performance in some cases-- whether this applies to Dink remains to be seen; admittedly Dink looks like a typical "made for porting to SDL" game, though. However, SDL does not offer any MIDI support as far as I know, so that would have to be done natively (and, while we're at it, why not allow people to code their own native xlib/cocoa/DOS+VESA/photon graphics drivers as well?). Abstraction is the key here, and (besides the effect of massively helping portability) it would yield a considerable code clean-up.

Wrt Allegro: Don't. It's a horrible mess on anything but DOS (and possibly Win32), and it doesn't even seem to try particularly hard to work with non-IA32 (Intel, AMD, Cyrix x86 architecture) CPUs.

-- Christoph