segra

There is OpenDune, and the entire savegame format is here https://github.com/OpenDUNE/OpenDUNE/blob/master/src/save.c#L79 It should be possible to write a script to read in a save game, then write out an INI.. cant remember all the details, so unsure if everything is possible in an INI.. but you could probably get pretty close

Hey @Fonic, Wow thats great! Thank you for keeping it alive, and yikes! cant believe its already 10 years old!!

You can view them all using DuneMaps http://dunemaps.sourceforge.net/ or source: https://github.com/segrax/dunemaps/

Although this really has nothing to do with the topic at hand, i figured, why not, because.... The Amiga version owns that crappy dos one (note: the graphics where all completely re-drawn for the PC Port) Unfortunately, these photos where not taken for closely examining the contents of the screen, and I really can't be bothered going and getting my Amiga(s) / games out of storage again at this point in time :) But it does show a nice black border around the screen... Which the top and bottom bars are missing during the intro... And for some strange reason, i cant find any of the photos of the actual game being played...

Ah, right now I understand... Yeah I'll look into that once I've got time, I'm not really sure how much work will be involved though... as they appear to have hacked up the EXE from my experiments (it contains missions all the way to some of the last scenarios... and just skips certain ones / phases in between) I do find it strange they went for this approach, over just removing the maps from the data file and renumbering the ones they wanted to keep... but maybe they lost the tool used to compress the data Also, has anyone noticed that the forum, when you quote someone and click to break the quote up... when you start typing, it comes out backwards? like its typing from right to left, instead of left to right?

Thats what should happen, but at the time of release, I hadn't seen that particular version (which is why it gives an MD5 error). I only spent ~4 months (while working a full time job) doing this entire port, so as you can guess, most of the time was spent coding and bug fixing, not hunting for demos :) All my ratios/resolutions are based on the original images in the data, thus, to me, a 2x-scale should be 640x400 (as all images in the DOS version are 320x200), thats why I told dosbox to cap the size to that resolution. 320x200 is considered a 4:3 ratio with 'non-square pixels' ( and it really depends on your particular screen/tv as to how many vertical lines you have )... https://en.wikipedia.org/wiki/Computer_display_standard The reason it was decided to use the original image sizes as the base for the scaling, was simply because I ran into issues on various screens I tested on... originally a scale had been chosen which stretched the image, however the blurring becomes really terrible on a resolution of 2560x1440 (my monitor native res)... using the original image scale, it still looks clean While it probably would be nice for some users to be able to apply the original "blur" look, my work on Open Fodder is done (except for fixing any bugs which appear), i have no plans on adding anymore features or adding support for Cannon Fodder 2. The original goal was to get the DOS version running and fully complete-able, when it had about 20 sprites left to implement, hungover one Saturday morning, I made the call to add support for the 'Amiga Format Special Edition'... as it was fun when I was a kid, that then lead to adding full support for Amiga data, and Cannon Fodder Plus (which probably added about 2-3 weeks work onto the project in total) Partially, The disassembly of the DOS and Amiga version (including both Amiga Demos) is very similar, in most cases, you can compare the disassembly side by side - the exceptions being the graphics/sound routines... Most of that work was done just to add support for the Demos, thankfully the maps/collision data themselves on the PC version, are direct copies of the Amiga version (this can be seen in the original dos engine, which does an endian flip when it loads them) While I'm still not entirely sure, I do believe the game was written in assembly, a number of items found throughout the disassembly gave me this impression - such as jumps from the middle of a function into another function... the use of global variables for everything instead of using the stack to push parameters to functions (in some cases, the contents of the global vars are pushed to the stack prior to a function call, the called function then clobbers those variables, and on return, the variables are restored... and in at least 2 instances, this was done before a Loop (all this is changed in Open Fodder, function parameters are now used ) There was also large amounts of game logic, which was laid out in such a way, that it clearly wasn't basic if/else statements (of course, they could of simply been using a large amount of GOTOs in these locations.. but unless the original code is released, or one of the devs speaks up, we will never know) The static images are mostly 320x260 in the Amiga version (but some are smaller), it does top/bottom/left/right 'Letter boxing' on practically all other screens (you'll notice in OF, the Amiga version only has the black border at the bottom on the recruitment screen), whereas the original had it on all 4 sides. numerous hours where spent weighing up the cons/pros of the various possible outcomes, and a 'middle ground' was selected, to prevent constant changing of the game window resolution. The 'middle ground', is the in-game resolution of 320x225 (I'm not sure why this is, 225 and not 224... as 0x0F tiles * 16 pixels height = 224, not 225)... is used as the multiplier basis of the window height, and all images are shrunk from 320x260 to 320x225. Thankfully, this has no noticeable effect... as this entire ordeal was a massive pain, which considerable time was spent trying to rectify... generally to find that one 'edge' case, which didn't work properly. This also led to the discovery that the original game suffered from this bizarre setup... as the mouse is restricted from going below about the 230 pixel mark.. even on screens where buttons exist to the 240-250 mark... this is most noticeable on the Amiga Format Special 'level selection' screen, and the Cannon Fodder Plus Quiz screen, as you cant go all the way to the bottom of the buttons Rob

Yeah, There is a link to GOG in the Readme for obtaining the Retail data, That demo works fine, it will give you an MD5 warning, but it will still work (Just put it in the Dos_CD directory). Cannon Fodder 2 isn't really supported, but it will start up (it contains a number of sprites which are not handled, sound effects, and some of the mission data is missing) Its also worth mentioning, the data included with that CF1 Demo... is actually the full Retail data (The 'Game Won' image has been changed, apart from that its 100% identical), they simply modified the mission table in the executable. You're missing the visual studio 2013 run-time, x86 and x64 versions are available from here: https://www.microsoft.com/en-us/download/details.aspx?id=40784 Yeah, the WAVs are extracted from the Amiga version - as this version hasn't been available for purchase for 20 years now, they should be in a separate archive... however because of their inclusion, i never bothered to implement the DOS music player... in my opinion, the music with the DOS version sucks, after I moved from the Amiga to Dos.. back when I was about 9, i spent hours trying to figure out why the voice track on the intro didn't work :) We've been working on the assumption the 'Amiga Format Special' was given out as a free demo of the game (I couldn't track down any copyright notices, or anything at all about it.. even after reading through the Amiga Format magazine it was included on), so we figured, why not, its two missions, hard to track down, and not available since the December 1993 magazine came out, its also difficult to extract from the Amiga disks. Open Fodder is running in multiples of the original resolution (320x200 - all the graphics are built to this resolution), with the built in SDL2 feature to stretch the image to the window size... if you start it up, and press the '-' key, the resolution will decrease.. all the way to 320x200, pressing '+' will increase it in multiples of 320x200 (assuming you're using the DOS version... the Amiga version uses the Amiga resolution) - until it hits full screen resolution. Playing in DosBox with aspect=true, appears to make the images stretched, Open Fodder in this screenshot is running in a window 640x400, DosBox was set to start in 640x400 with aspect=true... (however it appears to be closer to 533x400) The 'Load' / 'Save' text is very blurred

Hello All, drnovice dragged me here :) So I'm just going to explain how this problem was solved in Open Fodder Late last year, we spent many hours arguing about aspect ratios in Open Fodder... many long hours... In the end, we went with the original aspect ratio, too make matters even more difficult, the Amiga and Dos version have two different screen heights ( Dos: 320x200, and Amiga 320x260)... So Open Fodder, appropriately changes the Window height after you select a version See Here: https://github.com/segrax/openfodder/blob/master/Source/Fodder.cpp#L3200 In the Window Class (This is all SDL2, so not sure if Dynasty is using SDL2), instead of taking the screen resolution and resizing the game to suit... we take the original game resolution, and multiply it. Keeping track of a multiplier, rather than the current window size. https://github.com/segrax/openfodder/blob/master/Source/Window.cpp These functions are important to how it works: WindowIncrease, Increase the window multiplier by one if possible, if not possible, switch to full screen mode WindowDecrease, Decrease the window multiplier by one, if we're greater than the original screen size... (or drop out of full screen mode) CalculateFullscreenSize,Find a window multiplier which is greater than the full screen resolution, and return one less than that RenderAt , calculate the size difference between the window, and the surface size... and draw the image in the middle This allows the user to either hit F10 and full screen it, or press the + key to increase the window size, while staying true to the aspect ratio... depending on your monitor, you may get the 'black borders' once you hit full screen mode... Also on startup, it calls "CalculateWindowSize"... which finds a multiplier that is roughly half the size of the current screen resolution.. we found this to be a nice window size to start with Anyway, just my two cents Rob

Yeah, I just couldn't help myself though ;)

hey thats pretty cool :)

i need this box, ive only got this one for Amiga! too bad its bidding and not buy now :P

There is one of these for sale right now (black disks), sadly the back of the box is ripped :( http://www.ebay.com.au/itm/Dune-II-IBM-PC-MS-DOS-Classic-Real-Time-Strategy-Frank-Herberts-Dune-/131534473383?pt=LH_DefaultDomain_0&hash=item1ea010c8a7

Hey MrFlibble, Yeah its been awhile :) Pretty good, yourself?

Also on the seed topic, you can change the map seed and the map will change as you type (easy way to select a terrain)

Working fine on windows 7 for me :)