Volca on 6/11/2007 at 07:14
Thanks!
Quote Posted by sparhawk
And of course there is always the issue that with an open source code, you can make it run natively on Linux as well. :)
It does :) Gentoo linux is my primary OS...
Quote Posted by sparhawk
So if you plan to make the editor as well, this is great news, because seeing how much work is still down with Dromed, I think there would be no problem that this gets stale. :)
It will be an extra work, and not an easy one. But If I imagine the possibilities, it really starts to look as an interesting project. For example script debugger, event logger for play-tests (to find out what went wrong), right mouse context menu for objects (Properties, Links, etc.), material editor, drag and drop object handling, etc. People will have to say what they want in there to make it work. This is a far feature...
242 on 6/11/2007 at 09:50
Quote Posted by sparhawk
The second goal can only be achieved if dromed is also be reimplemented. Otherwise you are locked to the capabillities that dromed provides. Nothing with new features, because dromed supports it. So you need either a seperate editor for the new features, which acts like a add-on to dromed, or a complete new app.
Even now OPDE renders missions in 32-bit colour and image looks definitely more vivid than original. I imagine some dynamic shadows also possibly can be implemented without needing to modify existing missions. Or beautiful sky, proper fog, bloom, depth of field effect etc. Well, it won't hurt to dream a bit :) I'm fully aware that's years of hard work.
Volca on 6/11/2007 at 10:32
Quote Posted by 242
Even now OPDE renders missions in 32-bit colour and image looks definitely more vivid than original. I imagine some dynamic shadows also possibly can be implemented without needing to modify existing missions. Or beautiful sky, proper fog, bloom, depth of field effect etc. Well, it won't hurt to dream a bit :) I'm fully aware that's years of hard work.
I find the idea of using parallax or relief mapping to be quite cool :)
sparhawk on 6/11/2007 at 10:33
Quote Posted by 242
Even now OPDE renders missions in 32-bit colour and image looks definitely more vivid than original. I imagine some dynamic shadows also possibly can be implemented without needing to modify existing missions. Or beautiful sky, proper fog, bloom, depth of field effect etc. Well, it won't hurt to dream a bit :) I'm fully aware that's years of hard work.
Yes, of course this is quite nice to have. Already to ensure that thief will continue to run is a great prospect, because I have several older games which I no longer can run, because VMWare sucks at running games, and even on Windows 2000 they no longer work. :( For some games you can use DosBOX, but for some you simply have to wait until your machine is powerfull enough to emulate more advanced features.
But the point is, that you can do only so much to make it look better. It's still an outdated engine after all, and using bigger textures or making more highres models can not change that, because there is a limit if the editor doesn't go along. I'm erally quite happy about this project already as it is, no doubt about it, but if dromed is also ported, then it will be heaven, :) because it can run all the old stuff on top of allowing new missions to make use of the more advanced features. :D
AFAIK Hammerite Imperium cited as one reason of their slow progress that they run into so many limitations for their ideas, because of the old technology. And they don't mean the engine itself, they mean the editor with that.
AbYsMaL_-_WaRT on 6/11/2007 at 14:49
Quote Posted by ZylonBane
Code:
while(1) {
a++;
b++;
print("A = " + a);
print("B = " + b);
}
There. From the perspective of the user, A and B are, for all practical purposes, being incremented simultaneously.
Idiot.
Wow! ZB is a real douche bag
You remind me of my old friend.
DX-455 on 6/11/2007 at 23:17
yeah but he is right, for what it's worth.
Volca on 7/11/2007 at 08:30
Quote Posted by DX-455
yeah but he is right, for what it's worth.
Not that it makes any difference. The discussion was about observation of the system, and it's determinism. Dark obviously has to be deterministic, and those different observations of the same system on different machines are caused by different frame timings.
The per-frame updates in Dark work just like in any other game - the system iterates through all the updaters (input, physics, AI, tweqs, etc), then renders the result. If a timer did not manage to end the previous frame, in the time the timers were evaluated, it will be evaluated the next frame with some error accumulated. This error will cause the non-deterministic behavior in some scenarios, not the way the engine is coded. I'd say the mission editor is here to blame for creating a race-condition like situation.
I just hope not to open a new flame war by this. :rolleyes: ;)
hopper on 7/11/2007 at 10:39
Quote Posted by AbYsMaL_-_WaRT
Wow! ZB is a real douche bag
You remind me of my old friend.
I'm pretty sure the maximum acceptable time lapse for snarky retorts in a thread is less than two years.
nident on 7/11/2007 at 10:50
Well, if you want to point out the stupidity of ZB (who states "Occupation: programmer" in his profile), you should note that he also wrote this:
Quote:
So the closest a single-core system can come to simultaneity is to do things so quickly that they APPEAR to be happening simultaneously. Multithreading is only one way to do this. Another way, a way that's as old as gaming itself, is to just call a whole bunch of subroutines (each subroutine handling a particular game SYSTEM) from a main loop.
That's beyond hilarious.
OrbWeaver on 7/11/2007 at 11:38
Quote Posted by nident
That's beyond hilarious.
It's correct. What exactly is your criticism of what he wrote there?
