Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ciehoo]

Updated the main post with SOURCE *gasp*

[Sean Mirrsen]

Just noticed that you've tried to prove a point to me. Point taken, but when I still found modelling interesting, I churned out three-four models per day for my TA:Spring mod. So I know it's possible to make the models fast, but whether or not it's practical in terms of the Ogre engine and framerates remains to be seen. I'll just make an option switch for sprites then.

[Ciehoo]

Just noticed that you've tried to prove a point to me. Point taken, but when I still found modelling interesting, I churned out three-four models per day for my TA:Spring mod. So I know it's possible to make the models fast, but whether or not it's practical in terms of the Ogre engine and framerates remains to be seen. I'll just make an option switch for sprites then.

Fine by me As I said - I'm not really for it, but if someone else does the job, and it proves popular, then why not. Of course it would be best if everyone focused on the core project goals, but as it's open-source, then there's no way to control that.

[Sean Mirrsen]

I would point out that making it use sprites would not mean any additional work in regards to content (just look at the latest graphics set thread, that thing's gorgeous) again, but I think there's no point now. I'll go look at that code...

[Footkerchief]

I would point out that making it use sprites would not mean any additional work in regards to content (just look at the latest graphics set thread, that thing's gorgeous) again, but I think there's no point now. I'll go look at that code...

Just musing here, but I doubt DF makes it easy to grab the tile for creatures not in the current Z-slice.  I imagine you'll have to re-create the code used to read the charset/graphics BMPs, and possibly also reproduce the logic for applying status icons (bleeding, drowning, etc.) to creatures.

Bonus points if you use terrain tiles as the textures for terrain cubes.

[Sean Mirrsen]

Um, hello? Providing the right memory hook can be found, it is possible to get ALL of the data for the creatures and items on the map. And DF's tile settings are in the raws, not to mention the memory as well.

And yes, that was my initial thought as well. Maybe not ONLY the tile, but at least a certain background overlaid with the tile.

[Ciehoo]

Just musing here, but I doubt DF makes it easy to grab the tile for creatures not in the current Z-slice. 

As all the creatures (including dead ones) are stored in one big list, it's possible to get the data very easily. In fact, that's the way the dwarves in the "demo" are displayed.

I imagine you'll have to re-create the code used to read the charset/graphics BMPs, and possibly also reproduce the logic for applying status icons (bleeding, drowning, etc.) to creatures.

The loading code is pretty simple to implement. Matching graphics to creatures is a bit harder, as it requires some poking in assembly but still, very doable. The status icons - didn't look at that part of the code yet, but it's probably saved in some flags somewhere.

But all in all, still not on my priority list, so don't hold your breath for any code from me.

[Sean Mirrsen]

Oh, come on. Surely the creator of Dwarf Companion can help out in this (or at least the program itself). I know it just reads the memory from without, but it does it in real time... so status icons won't be any serious problem for a serious coder. The graphics are mostly defined in one big file, so a simple parser akin to the one used in Modbase can work, and the only required information on the unit would be its type and state/profession.

[Footkerchief]

Oh, come on. Surely the creator of Dwarf Companion can help out in this (or at least the program itself). I know it just reads the memory from without, but it does it in real time... so status icons won't be any serious problem for a serious coder.

I wasn't saying it would be a hang-up by any means.  I'm just thinking out loud.  There's also the multiple-creatures-in-same-tile situation to consider. 

[monolar]

Currently reading the code and it reads quite ok apart from this insane assembler part - thanks for all this!!

I'm not sure if my skills are good enough to expand it but i'll definitely try to fiddle around with it - once i install all the VS stuff on my windows box - i only code on my mac currently.

And i think the code is documented good enough to get a grip quickly. My only gripe is GEGUI which i never liked for a purely subjective irrational reason - could just be the default gui appearance, which is completely fugly.

EDIT:

I wonder if maybe it would even be worthwhile to use this to create basically the same kind of interface as the standard DF with some addons:

  - Zoomable map (to some degree)
  - make everything customizable through graphical tilesets, basically expanding the current capabilities.
  - better interface?

Anyway, how to get commands to the interface, assuming we would want to hide the DF window and recreate parts of the interface?

[Ciehoo]

Currently reading the code and it reads quite ok apart from this insane assembler part - thanks for all this!!

Hey - the AsmCall object is the best documented piece of code in the whole project

I wonder if maybe it would even be worthwhile to use this to create basically the same kind of interface as the standard DF with some addons:

  - Zoomable map (to some degree)
  - make everything customizable through graphical tilesets, basically expanding the current capabilities.
  - better interface?

As it is open source now, anything can be done, what can be thought. (how it will run is another thing altogether).

As far as I'm concerned, I thought about bringing the interface up to par with similar commercial games, with objects themselves being more interactive. I think it can be done pretty reasonably if more people work on it.

Anyway, how to get commands to the interface, assuming we would want to hide the DF window and recreate parts of the interface?

Either by replicating the underlying menu code in C++ (even using AsmCall to jump out into appropriate menu handlers), or poke changes directly into DF data, and let the game loop make sense of it.

[monolar]

Okay, after some reading i understand the injection hook for the most part - thanks to codeproject.com and of course msdn.

What i don't understand is this:

DWORD WinMainLoc = 0x00518C70;

in "Dwarf Launcher.cpp". How did you derive this address? I assume it is DF version specific!?

[LegoLord]

I just want to say that this looks very impressive.  Keep up the good work dude.

[Ciehoo]

Okay, after some reading i understand the injection hook for the most part - thanks to codeproject.com and of course msdn.

What i don't understand is this:

DWORD WinMainLoc = 0x00518C70;

in "Dwarf Launcher.cpp". How did you derive this address? I assume it is DF version specific!?

Yes it is - it might be possible to do it in a more universal way, but I needed a way to clobber the main game loop, to provide custom message handling, and skip rendering. This was the most obvious solution. Anyway, as far as I recall, it's not that hard to find the location, and update it for other versions.

To describe the launcher code, as it's not documented:

Code: [Select]

#ifdef __ASM_DEB
uchar int3; // debug the assembly code obviously
#endif
uchar pusha; // save all registers
uchar push1; // command opcode for pushing "OgreDwarf.dll" pointer on the stack
DWORD OgreDwarfPtr; // previously mentioned "OgreDwarf.dll" pointer
ushort call1; // command opcode for calling a library function
DWORD LoadLibraryPtr; // LoadLibraryA adress (result of the call is in EAX register -> handle to the library
uchar push2; // command opcode for pushing "CustWinMain" pointer on the stack
DWORD CustWinMainPtr; // previously mentioned "CustWinMain" pointer
uchar push_eax; // push OgreDwarf.dll library handle on the stack (the arguments are pushed in reverse order)
ushort call2; // command opcode for calling a library function
DWORD GetProcAddressPtr;// GetProcAddress pointer (result in eax) our exported library func
ushort call_eax; // command opcode for calling the address stored in EAX
uchar popa; // restore all registers to their previous state
uchar retn; // return to previous function (the one that called "WinMain"
uchar OgreDwarfStr[12]; // "OgreDwarf.dll"
uchar CustWinMainStr[12];// "CustWinMain"


[Drunken]

I may be wrong about this, and even if I am right it is probably irrellevant but:
The fact that this is released under a global public licence means that if we make this project and it works well and everyone likes it and then toady gets to the presentation arc...
It would be nice if toady could use this. He has always been against doing such things and it is highly unlikely that he would want to use it but still it seems good to leave it open as an option.
Again I might be wrong about this, it is possible that Ciehoo doesn't want to hand this project over to Toady free of charge or doesn't want it used as an official part of DF but I doubt this.
What I am proposing is a new type of licence that I dont know has ever been tried before: GPL exception. So put a disclaimer in that if Toady specifically as an entity wants to use any or all of this code in a proprietary project he does not have to open the source of that project, or make it free. I don't know much about copyright law but I think that the current licence doesnt actually mean he has to open source to use it. But it still forces him to keep the game free. Mind you that might be a good thing.
Thoughts anyone? I am probably just talking out of my arse.