Jump to content

OpenDune

Xaroth

By Xaroth
in Dune Editing

 Share

Recommended Posts

  • 1 month later...
  • 1 month later...
  • 8 months later...
  • 1 month later...
MrFlibble

MrFlibble

Posted
Posted

Yea, and get the Gravis Ultrasound patch for high-quality synthesized music :laugh:

BTW, I've found out an alternate method of getting higher quality music in Dune 2. If you get TiMidity++ with Windows synthesizer (TWSYNTH), it will install an alternate MIDI synthesizing driver you can use with DOSBox. It is my understanding that the driver is soundfont/patch dependent, meaning that you can vary music quality depending on what patch set you have. So you can use EAWPATS GUS Patches to get high-quality music in DOSBox that way too.

  • 2 weeks later...
MrFlibble

MrFlibble

Posted
Posted

In a bit belated news, TrueBrain has posted in the OpenDUNE Developer's Blog that the current stage of the project is nearing completion:

[P]rogress report:

Functions done: 1163 / 1229 (94%)

Functions named: 1180 / 1229 (96%)

That says most of it. We are nearly done converting all functions to real C (not my fake assembly-C). The functions that remain are related to sound' date=' voice and music. It has little to do with OpenDUNE itself, so it slowly walks after us.

The rest of OpenDUNE is done. Including all the bugs, the weirdness and the exact identical behaviour Dune2 had. I am so proud :D When we started this project, I was hoping it would finish some day .. just never imagined it would. Makes me want to say HA! to all those pessimists who told us this was the wrong approach, that it would never be finished, that we should join (team up) with existing projects, ... Well .. for those I only have to say: HA!

There, I enjoyed doing that.

So, I am sure you now wonder: and now? Well .. a lot.

During our conversion, we kept the 16bit memory allocation. Its a pain. It does not allow for any extension in any way. So, the job that followed immediately after finishing conversion was: start moving the 16bit pointers to real pointers. This is not as easy as it sounds, as there are tons and tons of references in the 16bit world to structs and arrays. Simply moving them to the 32bit/64bit world causes many errors, because calls in the 16bit world can no longer see these objects.

A few days ago we managed to move out all UnitInfo, StructureInfo, TeamInfo and HouseInfo to the 32bit/64bit world, which was a HUGE milestone. Today we are very close to move Widgets out, which is around 80% of the work that has to be done for that. While at it we are also moving other variables and pointers from the 16bit world to 32bit/64bit when we feel like it, and the list of variables that needs doing is getting shorter and shorter.

The other thing we have been working on in parallel, as they kinda depend on each other, is dumping the information from Dune2.exe in a format we can work with, without needing Dune2.exe. In theory it would be possible to just read Dune2.exe on startup, read the information, and use it. But because there are many many pointers (which we would have to convert, which requires knowing where it used to point to), we decided to dump this information in plain C, in so called table-files. These are just files where you see endless variables defined for every entry. See for example:

http://svn.opendune.org/trunk/src/table/unitinfo.c?mode=view#filecontent

The content of the file is converted one-on-one from Dune2.exe 1.07EU. We simply parsed the information via a simple tool. So we start to depend less and less on Dune2.exe, which is only for the better :D

What else ... yeah, we named many more variables. And we also see a lot of unused variables. At least we know 100% sure they are unused now, as if not, we would have noticed by now (by the reason we converted everything :D Shall I say it again? We converted EVERYTHING).[/quote']

  • 3 weeks later...
Xaroth

Xaroth

Posted
  • Author
Posted

Last night was a nice little development sprint, Truebrain and glx were committing changes faster than I could read through, but it did lead to being able to drop the dependency of the emulation layer.

Truebrain posted a better explanation

What this means, basically, is that from this point forward we can start optimizing, improving and reworking things in OpenDUNE.. all the ideas we had in the past can now, technically be implemented (as long as it goes with the vision of the development team ofcourse)

  • Upvote 1
  • 1 year later...
drnovice

drnovice

Posted
Posted

Ok, I downloaded opendune c++ source code and I tried to compile with Visual Studio 2010 (opening opendune_vs100.sln)... just trying to set a new unit object parameter regards HouseID that deviates the unit targeted (I called it deviantHouseID) as personal Deviators Patch and it seems to work (I tried a Scenario with 1 Atreides Deviator, 1 Harkonnen Deviator and 1 Ordos Deviator). I was inspired by this... :)

 

However I noticed that Autoscroll pointer works only if it selected human unit, and if you use Scroll with mouse click, it snaps away on max of level position (e.g. if you left mouse scroll on top, it snaps away on top limit of level!). Why? The cycles are too much quick?

 

 

EDITED

I found something:

https://github.com/OpenDUNE/OpenDUNE/commit/f437c3ca0729fcd9a98b2ede49e997db953cde8a

+

https://github.com/OpenDUNE/OpenDUNE/commit/f33e0e15ac6abae9cfd1e2a1ac83782a21601f00

 

Tomorrow I'll try at work with VS2010. :)

 

 

An example made on YouTube:

  • 3 years later...
drnovice

drnovice

Posted
Posted (edited)

Resuming this topic, because OpenDune is still the most faithful porting of Dune2 original game.

I'm trying to bring SDL1.2/SDL2.0 support even for Win32, because SDL is very good and simple to manage on Windows compiling by MSVC.

So I wanted to give a Zoom In/Out feature (+/- keys) and a complete toggle fullscreen (F11 or Alt+Enter) mode, since with current default WinAPI code there is only possibility to manual resize window, but breaking original aspect ratio of game...

If anyone would like try my Fork, please go here: https://github.com/drnovice/OpenDUNE

consulting PR changes info: https://github.com/OpenDUNE/OpenDUNE/pull/281

 

Moreover: currently I can't try to compile on Linux/Mac, can anyone try if these features work fine on those systems and report feedback here or on github? Thanks!

Edited by drnovice
  • 2 weeks later...
  • 1 month later...
drnovice

drnovice

Posted
Posted

We're waiting for approval by an opendune admininstrator.

This changes can be ported even on Dune Dynasty if owner still can use SDL/SDL2 to graphics.

But I don't understand why to port enhancements and improvements of Dynasty into OpenDune project, since this one is just a 1:1 porting by 16bit original game. I think OpenDune should remain a base opensource project to start if anybody would create something new (like Dynasty) on Dune2 clone games.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.