16-bit colors, and other things
New to the board, but not to FreeDink.
Questions:
1. What language is FreeDink written in?
2. Is it possible to replace the pseudo-3D graphics with, say, sprites similar in style to the Zelda games?
3. Is it possible to alter the HUD (Heads Up Display), so it's an actual HUD, similar to The Legend Of Zelda: A Link To The Past or Mega Man X? I really want to increase the playable screen area.
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
5. The game I want to make is basically a combination of ALTTP and Link's Awakening, with Job Classes thrown in, which is inherentaly modifiable in terms of:
*Specific game mechanics
**Scriptable stat and damage formula database, which includes:
***A do-it-yourself actor database for every actor in the game (by DIY, I mean the modder can rewrite and relabel all the stats which make up an actor, and what these stats do)
***A DIY class database for every class and meta-class, all of which are scriptable
****Meta-class data being race and gender of actors, among other things.
*Images
*Sounds
*The menu system/module
*The event scripting and text display systems/sub-modules of the field module
6. Is it, in your opinion, a good idea to use the FreeDink engine as a base (or at least a starting point) for a game engine which accomplishes all of the above? I'm not a coder, but I start school in the fall for Computer Science, so this is on my to-do list.
General Planning and Layout:
*Menu Module
**Opening Movie (skipable)
**New Game
**Continue
**Credits
**Configuration
**Debug Mode
**Shops
***Shop database
****Items sold
****Item Price (if this isn't part of the item database, that is)
****Price modifier
**Field Menu (This may be part of the actual field module, IDK for sure - depends how fast the game can load modules)
***(Scriptable stuff that links various stats together)
***Item Menu
***Equipment Menu
***Magic Menu
***Status Menu
***Configuration
***Save Gamesave/Load Gamesave/Delete Gamesave
*Field module
**Event Scripting sub-module
**Text Display sub-module
**Battle sub-module
**Other stuff I don't know enough about as of yet
*Database Module
**Actors database (everything in the game that you can kill and which can kill you, including yourself)
**Classes database
***Meta-classes database
**Formulas database
**Abilities database
**Items database
**Other things I forgot.
Questions:
1. What language is FreeDink written in?
2. Is it possible to replace the pseudo-3D graphics with, say, sprites similar in style to the Zelda games?
3. Is it possible to alter the HUD (Heads Up Display), so it's an actual HUD, similar to The Legend Of Zelda: A Link To The Past or Mega Man X? I really want to increase the playable screen area.
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
:red heart : remaining health in decimal numbers :green heart: remaining mana in decimal numbers
5. The game I want to make is basically a combination of ALTTP and Link's Awakening, with Job Classes thrown in, which is inherentaly modifiable in terms of:
*Specific game mechanics
**Scriptable stat and damage formula database, which includes:
***A do-it-yourself actor database for every actor in the game (by DIY, I mean the modder can rewrite and relabel all the stats which make up an actor, and what these stats do)
***A DIY class database for every class and meta-class, all of which are scriptable
****Meta-class data being race and gender of actors, among other things.
*Images
*Sounds
*The menu system/module
*The event scripting and text display systems/sub-modules of the field module
6. Is it, in your opinion, a good idea to use the FreeDink engine as a base (or at least a starting point) for a game engine which accomplishes all of the above? I'm not a coder, but I start school in the fall for Computer Science, so this is on my to-do list.
General Planning and Layout:
*Menu Module
**Opening Movie (skipable)
**New Game
**Continue
**Credits
**Configuration
**Debug Mode
**Shops
***Shop database
****Items sold
****Item Price (if this isn't part of the item database, that is)
****Price modifier
**Field Menu (This may be part of the actual field module, IDK for sure - depends how fast the game can load modules)
***(Scriptable stuff that links various stats together)
***Item Menu
***Equipment Menu
***Magic Menu
***Status Menu
***Configuration
***Save Gamesave/Load Gamesave/Delete Gamesave
*Field module
**Event Scripting sub-module
**Text Display sub-module
**Battle sub-module
**Other stuff I don't know enough about as of yet
*Database Module
**Actors database (everything in the game that you can kill and which can kill you, including yourself)
**Classes database
***Meta-classes database
**Formulas database
**Abilities database
**Items database
**Other things I forgot.
2. Is it possible to replace the pseudo-3D graphics with, say, sprites similar in style to the Zelda games?
Sure! This should be a simple matter of replacing the original graphics with more Zeldaish graphics? (There isn't any "real" 3D graphic stuff in Dink, and you can download the base graphics here (they might be readily available with FreeDink as well, can't remember))
3. Is it possible to alter the HUD (Heads Up Display), so it's an actual HUD, similar to The Legend Of Zelda: A Link To The Past or Mega Man X? I really want to increase the playable screen area.
You mean that the screen should stay centered on the player as you move, no screen changes and such? (Talking about HUDs makes it sound more like you wanted to recreate Wolfenstein 3D =)
This is something that a number of people have actually requested as a feature in Dink over the years, but I don't know how easy it would be to change the engine to accomodate that. (I'm not a programmer, I know nothing of the internal workings of FreeDink)
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
This is a feature that would be doable with the internal scripting language (DinkC), but I'm not sure if that would be ideal (lots of awkward scripting involved), if you (will) have the skill to program it directly into the engine.
6. Is it, in your opinion, a good idea to use the FreeDink engine as a base (or at least a starting point) for a game engine which accomplishes all of the above? I'm not a coder, but I start school in the fall for Computer Science, so this is on my to-do list.
No. =) I'm not an authority on the subject either, so take this with a grain of salt, but it sounds like far more trouble than it's worth. I would try looking for an engine that's inherently better suited for a Zelda clone, e.g. Seth's Novashell Game Creation System might be worth a look. (It's supposedly powerful and flexible, and has the scrolling HUD you mentioned built in)
Sure! This should be a simple matter of replacing the original graphics with more Zeldaish graphics? (There isn't any "real" 3D graphic stuff in Dink, and you can download the base graphics here (they might be readily available with FreeDink as well, can't remember))
3. Is it possible to alter the HUD (Heads Up Display), so it's an actual HUD, similar to The Legend Of Zelda: A Link To The Past or Mega Man X? I really want to increase the playable screen area.
You mean that the screen should stay centered on the player as you move, no screen changes and such? (Talking about HUDs makes it sound more like you wanted to recreate Wolfenstein 3D =)
This is something that a number of people have actually requested as a feature in Dink over the years, but I don't know how easy it would be to change the engine to accomodate that. (I'm not a programmer, I know nothing of the internal workings of FreeDink)
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
:red heart : remaining health in decimal numbers :green heart: remaining mana in decimal numbers
This is a feature that would be doable with the internal scripting language (DinkC), but I'm not sure if that would be ideal (lots of awkward scripting involved), if you (will) have the skill to program it directly into the engine.
6. Is it, in your opinion, a good idea to use the FreeDink engine as a base (or at least a starting point) for a game engine which accomplishes all of the above? I'm not a coder, but I start school in the fall for Computer Science, so this is on my to-do list.
No. =) I'm not an authority on the subject either, so take this with a grain of salt, but it sounds like far more trouble than it's worth. I would try looking for an engine that's inherently better suited for a Zelda clone, e.g. Seth's Novashell Game Creation System might be worth a look. (It's supposedly powerful and flexible, and has the scrolling HUD you mentioned built in)
In addition to scratcher's replies:
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
1.
:red heart : remaining health in decimal numbers
2.
:green heart: remaining mana in decimal numbers
Percent-based Lifebar kind of does this. The red bar is still there, but it is percentage based, and the value is also shown as a number to the right of the bar.
As for mana, some of Erwin's stuff like Enter the Dead Dragon Carcass uses a mana bar. Maybe you could get rid of the bars and add a number value to the mana like the Percent-based Lifebar does.
4. Specific HUD question: I want to the Health and Mana meters to be simply Red and Green hearts, with numbers next to them which are your remaining amounts of health and mana. Sort of like this:
1.
:red heart : remaining health in decimal numbers
2.
:green heart: remaining mana in decimal numbers
Percent-based Lifebar kind of does this. The red bar is still there, but it is percentage based, and the value is also shown as a number to the right of the bar.
As for mana, some of Erwin's stuff like Enter the Dead Dragon Carcass uses a mana bar. Maybe you could get rid of the bars and add a number value to the mana like the Percent-based Lifebar does.
1. C.
2. Anything you like. Transparency is even supported.
3. No.
4. That's not a question since there's no question mark.
6. No. The amount of engine modification would be enormous.
Considering you don't know how to program, you should start off small and work upwards. A rocket enthusiast doesn't aim to fly to the moon for his first project.
2. Anything you like. Transparency is even supported.
3. No.
4. That's not a question since there's no question mark.
6. No. The amount of engine modification would be enormous.
Considering you don't know how to program, you should start off small and work upwards. A rocket enthusiast doesn't aim to fly to the moon for his first project.
Dink graphics are already sprites.
It looks like some of the others have interpreted your question as about creating a DMOD, but it sounds like you are thinking of modifying the FreeDink engine. Contrary to yeoldtoaste, I think if you are intending a career in computer science then charting a trip to the moon sounds like a great idea. I don't know if using FreeDink as a starting point is a good idea or not. If you do, you'll probably eventually be motivated to rewrite all of it.
I found this link with a quick search:
http://content.gpwiki.org/index.php/Game_Engines
Whatever you do, get your hands dirty and do it the hard way. You learn more that way
Then you won't ask the questions you did, because you'd realise you can program an engine to do anything if you know how to.
It looks like some of the others have interpreted your question as about creating a DMOD, but it sounds like you are thinking of modifying the FreeDink engine. Contrary to yeoldtoaste, I think if you are intending a career in computer science then charting a trip to the moon sounds like a great idea. I don't know if using FreeDink as a starting point is a good idea or not. If you do, you'll probably eventually be motivated to rewrite all of it.
I found this link with a quick search:
http://content.gpwiki.org/index.php/Game_Engines
Whatever you do, get your hands dirty and do it the hard way. You learn more that way

Pretty sure thats why people dream - if you reach for the ground thats where u end up

With point 3, it is possible, but to do that you would need to make significant changes to the Dink Source Code - it would probably be easier to just recreate the game in Novashell or some-such. The "thing" you are talking about is called scrolling, specifically, you want to turn a "flip-screen" into a "parallax scrolling" game... no mean feat!
Is question 3 about turning the screens into scrolling instead? I read it as asking whether it's possible to reduce the area the status bars (ie HUD) take up, in order to increase the size of each screen.
Anyway, if that's what's meant, then no not really. You could probably hack something involving sp_noclip and dink_can_walk_off_screen and then placing sprites to change screen or something like that, but it would be a huge pain for little gain. (Hey that rhymes.)
Anyway, if that's what's meant, then no not really. You could probably hack something involving sp_noclip and dink_can_walk_off_screen and then placing sprites to change screen or something like that, but it would be a huge pain for little gain. (Hey that rhymes.)
Didn't rabidwolf9 make a scrolling background? I remember seeing a video of someone demoing that. I think it was him. I'll have to look for it later.
Questions 3 and 4 are about changing the displays for stats and other stuff into stuff that's superimposed over the field area, instead of outside the field area as it currently is.
Here are some examples of a HUD hack for Mega Man X.
http://img651.imageshack.us/img651/553/regularlifebar.png
^Before the hack. Notice that health and remaining ammo are represented by tabs inside of bars.
http://img851.imageshack.us/img851/2728/numberlifebar.png
^After the hack. Not only do the numeric health and ammo counters take up less space than the bar-based health and ammo counters, but their display limit is only limited by the number of places you put in them. You could concievably increase health to two bytes, if you have five number places for health.
1. Less space taken up = more room for other stuff
2. Numeric counters = higher stat caps
I didn't realize that mana doesn't have a bar, instead the equipped spell has a recharge rate. In that case, you could display the equipped spells icon, and next to it a cool-down timer that counts down to zero. When it hits zero, you can cast that spell again. The rate at which it counts down varying depending on your Magic stat (or is it called intelligence - I don't remember).
HUD is anything that display's aspects of the game which is not part of the game environment, or a menu. Shooting game's have HUDs, platform games have HUDs - almost every game has a HUD of some kind, at some point in the game. Myst being the only exception I can think of.
I'm fine with every screen being the exact same size. TLEZ: Link's Awakening does the exact same thing (I believe this is what inspired FreeDink in the first place). This was done as a way to save RAM, since you only had to load 9 screens at any given time, plus go-to for the menu. 9 Screens being the screen you're currently on, and the 8 screens around it. With this built-in limitation, TLEZ:LA could spend more of it's meager Game Boy RAM on better graphics, better sound, more events, and more actors.
I woke up this morning with everything clear in my mind, and now I have to try to remember it.
I'm aware that FreeDink's graphics are actually 2D; that's why I referred to them as pseudo-3D. I think they were made by making a 3D model, and then taking 2D pictures of that model, and then combining those 2D pictures into an animation. Super Mario RPG does the exact same thing with sprites and I think the pre-rendered backgrounds, though it is somewhat 3D to begin with (because the pre-rendered backgrounds are superimposed on top of a 3D model, and there are collision physics for Mario's interactions with other actors and his environment).
And I see I forgot to ask the question for which this topic was named - how much work does FreeDink need for 16 bit (or *gasp* 32-bit) graphics?
Here are some examples of a HUD hack for Mega Man X.
http://img651.imageshack.us/img651/553/regularlifebar.png
^Before the hack. Notice that health and remaining ammo are represented by tabs inside of bars.
http://img851.imageshack.us/img851/2728/numberlifebar.png
^After the hack. Not only do the numeric health and ammo counters take up less space than the bar-based health and ammo counters, but their display limit is only limited by the number of places you put in them. You could concievably increase health to two bytes, if you have five number places for health.
1. Less space taken up = more room for other stuff
2. Numeric counters = higher stat caps
I didn't realize that mana doesn't have a bar, instead the equipped spell has a recharge rate. In that case, you could display the equipped spells icon, and next to it a cool-down timer that counts down to zero. When it hits zero, you can cast that spell again. The rate at which it counts down varying depending on your Magic stat (or is it called intelligence - I don't remember).
HUD is anything that display's aspects of the game which is not part of the game environment, or a menu. Shooting game's have HUDs, platform games have HUDs - almost every game has a HUD of some kind, at some point in the game. Myst being the only exception I can think of.
I'm fine with every screen being the exact same size. TLEZ: Link's Awakening does the exact same thing (I believe this is what inspired FreeDink in the first place). This was done as a way to save RAM, since you only had to load 9 screens at any given time, plus go-to for the menu. 9 Screens being the screen you're currently on, and the 8 screens around it. With this built-in limitation, TLEZ:LA could spend more of it's meager Game Boy RAM on better graphics, better sound, more events, and more actors.
I woke up this morning with everything clear in my mind, and now I have to try to remember it.
I'm aware that FreeDink's graphics are actually 2D; that's why I referred to them as pseudo-3D. I think they were made by making a 3D model, and then taking 2D pictures of that model, and then combining those 2D pictures into an animation. Super Mario RPG does the exact same thing with sprites and I think the pre-rendered backgrounds, though it is somewhat 3D to begin with (because the pre-rendered backgrounds are superimposed on top of a 3D model, and there are collision physics for Mario's interactions with other actors and his environment).
And I see I forgot to ask the question for which this topic was named - how much work does FreeDink need for 16 bit (or *gasp* 32-bit) graphics?
To get all the stats as a HUD superimposed on the playing area, looking however you like, would be fairly easy to do in a D-Mod's DinkC scripts. It's expanding the playing area to cover where the stats were originally that would be hard.
As for building it into the engine, I really don't know.
FreeDink has a truecolour mode I believe, the same as normal Dink 1.08. You can use up to 24 bit graphics, but again, no idea how much work would be needed to support 32 bit
As for building it into the engine, I really don't know.
FreeDink has a truecolour mode I believe, the same as normal Dink 1.08. You can use up to 24 bit graphics, but again, no idea how much work would be needed to support 32 bit

HUD is anything that display's aspects of the game which is not part of the game environment, or a menu. Shooting game's have HUDs, platform games have HUDs - almost every game has a HUD of some kind, at some point in the game. Myst being the only exception I can think of.
Dink does not have a HUD. Or, at the very least, referring to the status bar as a HUD is really, really awkward. (Hence the confusion -- that term should really be restricted to interfaces where the info is actually superimposed over the playing area, as in real HUDs)
I like the idea, though. Go for it.
(I can't imagine it being too complicated to program, or at least, should be leagues simpler than making the world scroll)
Dink does not have a HUD. Or, at the very least, referring to the status bar as a HUD is really, really awkward. (Hence the confusion -- that term should really be restricted to interfaces where the info is actually superimposed over the playing area, as in real HUDs)
I like the idea, though. Go for it.

32 bit graphics are just 24 bit with an 8 bit alpha channel. It supports all formats supported by SDL_image however transparency is a little weird.
For fun I decided to encode all of Dink's graphics into low quality JPG once which made them only take up a few megabytes.
For fun I decided to encode all of Dink's graphics into low quality JPG once which made them only take up a few megabytes.
Note: I don't know the FreeDink code as well as I know the original Dink engine. Beuc did a terrific job with cleaning up the code for reading the different .dat formats, and the DinkC script interpreter, but besides that, I wouldn't know.
Back to the point: what scratcher said. Dink's status bar and sidebars aren't "over" any playable area at all, so moving the info around wouldn't get you more visible space, it'd just require the game window to be smaller, or a smaller fullscreen resolution.
The gameplay area is 600x400. Of course, because you have the source, you can increase that if you want, but it may be more trouble than it's worth. Maps are stored with a 12x8 array of tile numbers, and tiles are 50x50. Changing the screen size would invalidate the map.dat format, and it would make the existing map editors useless, unless you change those as well.
Tilesets are 600x400 too. Again, 12x8 tiles. This isn't related to the map.dat format as far as I know, but if they're linked, hard.dat will need to be rewritten as well.
Changing the tile size to something other than 50x50 will invalidate hard.dat and you won't be able to use the original tilesets anymore. Which isn't all too bad for your purpose.
While the features you listed are at least somewhat doable in the (Free)Dink engine, I think Someone's right. Once you get the hang of it, and are aware of the restrictions and other oddities, you'll rewrite the entire thing yourself anyway. Alternatively, you can use Novashell, or one of the other engines listed on the page Someone mentioned.
Back to the point: what scratcher said. Dink's status bar and sidebars aren't "over" any playable area at all, so moving the info around wouldn't get you more visible space, it'd just require the game window to be smaller, or a smaller fullscreen resolution.
The gameplay area is 600x400. Of course, because you have the source, you can increase that if you want, but it may be more trouble than it's worth. Maps are stored with a 12x8 array of tile numbers, and tiles are 50x50. Changing the screen size would invalidate the map.dat format, and it would make the existing map editors useless, unless you change those as well.
Tilesets are 600x400 too. Again, 12x8 tiles. This isn't related to the map.dat format as far as I know, but if they're linked, hard.dat will need to be rewritten as well.
Changing the tile size to something other than 50x50 will invalidate hard.dat and you won't be able to use the original tilesets anymore. Which isn't all too bad for your purpose.
While the features you listed are at least somewhat doable in the (Free)Dink engine, I think Someone's right. Once you get the hang of it, and are aware of the restrictions and other oddities, you'll rewrite the entire thing yourself anyway. Alternatively, you can use Novashell, or one of the other engines listed on the page Someone mentioned.