The Dink Network

Is it safe to start using 16 bit .bmp graphics ? What will the new standerd be, or will newer versions of the engine make use of anything up to 32 bit?
Or is it just too early to say?

It's probably a bit early to say, however I'm pretty sure there will be 32-bit support..., once this all gets sorted out.

Well, Invertigo's Windowed Mode / 32 Bit already supports high-color bmps.

Remember, you can always convert from high color to the Dink palette, but you can't convert from the Dink palette to high color. So make your graphics in high color, and make the final decision when your D-Mod is near completion.

Is there anybody right now planning on remaking dink graphics to be viewed in a 32-bit color scheme? I realize this would either require remodeling or getting the models, or some kind of tricky tricks I don't really understand in photoshop, but is it do-able?

I suppose the arrival of 32 bit makes it more likely, but I always thought somebody (like Simonk) would make 3d variants of the bonca, pillbug and slayer.
That would have been cool!

I'm going to try to learn blender and start making a few creatures. Just wondering if anyone has thought about some standards for a basic starting set. I'm thinking I'll try these:
-24 bit
-Buildings at current size.
-People and interior items at 80% of current size. ( so Dink isn't taller than doorways.)
I suppose the real standard will probably be set by the first dmod with good graphics to use.
erm.....Is there an easier tut. for blender???

A. Why not 32 bit. The only thing you're loosing is alpha support, but it can be very useful at times.

B. Why not just remake the buildings to be 120% larger? I know that's not proportional to 80%, but whatever. I mean, who wants to play a character like the one in A Knights Tale 2 that is so tiny that he looks like a Warcraft II character (He was, IIRC)?

I wouldn't want buildings bigger to match dinks size mainly because dink (and other people) are large enough that you can't put a big dragon, or horses, or giant monster on the screen without crowding. Going smaller lets more action happen on the screen without the player getting crowded off and onto the next screen. I guess I'd just like to make a dragon act, well, kinda dragonish.
Half size is too small, but 80% looks good.
32 bit is great, but some weaker systems (ya, like mine... ) slow down with 32 bit. And 32 bit is good enough for photo quality. For game animation 16 bit or 24 bit would be a good comprimise.
Mabey gamename.ini should have a line specifying the color depth. As is Dink will usually run high color bmps (aproximating them in dink pallete,). As long as it continues to do so, I guess we'll just have to see what graphics become available.
Hey! I found some great Blender tuts here,http://blendedmind.i8.com/tutorials.html
Now I'll have complete new graphics in , erm....6 years.
Or so.

Numbers since I don't feel like typing a paragraph:

1) Still, you could make the graphics in 32 bit, and reduce them for certain d-mods.

2) Yeah, I see what you mean as far as size.

3) Well, I was thinking of putting the settings in like, main.c, so it could be author-defineable.

Well, how about your basic set of new graphics includes some more mythological characters. Orcs, Minotaurs, NEW evil wizards?

Well the idea behind messing with size is actually a good one, because the resolution can be changed, and to a certain extent, it could be very well done.

We could, say, leave dink's size the same, up the resolution, and increase the size of houses

The maps would seem bigger (and in all practical senses be bigger) and it could work out very well.

To be honest, tho, I'm not sure how much I'm going to mess with all this once it's out... I feel guilty for having all I have and not releasing it, and stupid for having it all and not doing anything with it, but at the same time, it's just so primitive at this point.. ah who knows, these upgrades may be really good for it.

That would be best for sure, but how hard is it to make the engine change screens while in higher res.? Also if we want to refine the sprite sizes, it would be good if sp_speed() could work in finer increments, like:
sp_speed(1, 2.5);