The Dink Network

Who wants new dink stuff?

We have hit a brick wall and are pretty much forced to rewrite the dink engine. From scratch. Yep. This is an undertaking that is feasible, however. Some of the source code can be reused. Here are the specs:

Engine Chart
Engine Notes

If you look closely (I'm not going to tell you where ) you'll find that this project has already been started. Some of the things planned:

* A new mapfile/savefile format. This will be tree-based, similar to XML format. A converter will be included.
* SDL/OpenGL graphics. Which to use is being debated.
* The new DinkC++ Engine will be used
* Side-Scrolling is being taken into consideration
* FastFile decimation. Face it, these absolutely suck. And they're good at it too. These will be replaced by either a zlib-based creation or a similar-to-.tar format
* A new sprite format. .MNG is being taken into consideration.

Hopefully, the mapfile/savefile format will be done by sometime tomorrow (Yep, we're moving right along).

Any comments?

.MNG format? I am unfamiliar with that extension. Would it not be possible to use .png format or is that a liscensed protocal?

Ummm, not to burst your bubble, but do consider finishing it within a small enough timeframe or there might not be anyone here left to release the new engine to...

I'm impressed. I have been trying high color graphics and this engine just can't make a screen fast enough to play smoothly. Still hoping for 800*600 whatever the color depth.

To answer your question, .mng is simply an animated .png. You can find more information here.

And Ric, I would like 800x600 also. Unfortunately, there are no graphics out there that can support that format. If you'd like, I can make an 800x600x32 format just for to screw around with.

Most games take a lot of time because they need to make content once the engine's done. Dink's not like that; once we've made the new engine, which Andrew wants to call Windemere (hey, why not), we'll provide conversion tools to allow backwards compatibility for DMODs.

This looks like fun.

Yay!

Note: I'll redo CVS for you by Friday. Finals suck.

After looking into it some more and talking with Redink about the subject I reconsidered my previous post.

If backwards compatibilty is possible and you can still use stuff from the original code as well as all the graphical resources, I no longer believe it will take 2 years to finish and I'm actually looking forward to it!

Hmm, this reminds me of a suggestion I should do. It's actually not my suggestion but one of a friend who is too lazy to post anything... Oh well...

Anyway, it is to make an spc-reader. *.spc is the extension for SNES-rom music (also some kind of windows certificate). According to this guy, it's better quality and still as small as MIDI.

Could you consider doing this? Please?

I'm not quite sure if you mean a .spc player, or a .spc plug-in for the Dink Engine. If you mean the former, you can find one here [Zophar's Domain].

One quick question though. Does he have any specific documents relating to SPC quality in comparison to MIDI? Also, why would you implement a reader for a Sound Processor dump off of an 8-bit console system? I find MIDI's work just fine, and are readily available.

Any comments on this?

SPC files are of WAY better quality than midi, they can't even be compared. They resemble mp3 quality, except that they are based only on the existing sound system of the SNES, which means it won't have superquality like normal MP3s, but that's mainly because the quality's the same as it is on the 16-BIT SNES, not 8 bit.

I agree that this is an excellent idea, implementing it in Dink. As a matter of fact, if this gets through I anticipate every d-mod to include at least a couple of those, as a lot of midis used in d-mods originate from songs played in SNES games.

If you can manage, please do this!

For some spc examples you should try this site.

I think SPC is wav sound activated by MIDI commands. I've got some conversion programs for SPC to wav or to mid, but the wav conversions are terribly big files, and you have to define the instruments yourself with the midi converter.

What about MOD support along with MIDI? I think its better quality than MIDI, and is used in more PC games.

Very excited to hear you guys are writing a new engine! I have a few questions and pardon if they have been answered elsewhere that I have not seen:

How many colors will it support?

What resolution?

Will it be a true isometric engine instead of faked? I so, I guess it would screw backwards compatibility huh?

Will the background scroll or keep the old-skool screen loading format?

Props to you guys coding this. Can't wait to see it.

How many colors will it support?

16777216. That's 32-bit color (24 + alpha).

--

What resolution?

640x480. At least, until somebody draws new graphics.

--

Will it be a true isometric engine instead of faked? I so, I guess it would screw backwards compatibility huh?

I don't know. Probably not - there isn't really a need.

--

Will the background scroll or keep the old-skool screen loading format?

This is being debated.

--

Props to you guys coding this. Can't wait to see it.

if you can support 800 * 600 can we still use 50 * 50 tiles? If not I could blend something up fast. Would 64 * 64 tiles be easier?

As for scrolling screens, I guess you could do this, but you'd need to have new placeable triggers to have something go off in a certain region. This could emulate the base scripts.

I think it would play nicer with scrolling screens, but that means recoding move commands as well, as the coordinates would no longer fit.

but that means recoding move commands as well, as the coordinates would no longer fit.

The move commands could have an extra parameter, the mapscreen. This would also allow long distance travels, across screens:

//on screen 1
move_stop(1, 2, 300, 1, 65);

would let Dink walk down from screen 1 to screen 33 to screen 65.

but that means recoding move commands as well, as the coordinates would no longer fit.

Well, if it works as I am imagining it, Dink would stay in the center of the screen, and the background would scroll. Is that what we're talking about?

Dink could stay centered while the map scolls past or map scrolling and Dink moving could be controled sepparatly ( like in infinity engined games.) As it is you could almost do it the first way just by using a large bitmap sprite that moves when the right keys are pushed while Dink gets a different brain. That just doesn't look right though.