Compiling the OHRRPGCE from source

Ask and answer questions about making games and related topics. Unrelated topics go in that other forum.

Moderators: marionline, SDHawk

User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Compiling the OHRRPGCE from source

Post by Bird »

Has anyone some experience with compiling the OHRRPGCE from the source code? I'm facing a lot of difficulties, since Quickbasic was abandoned. There are so many different C compilers! Which one do you use? Can I use GCC instead of Visual Studio? Shouldn't it be enough to set the PATH values to C:\mingw\bin, where the C compiling command is located after having GCC installed? Surely the other PATH values have to be set too, but this bloody Sconsscript tells me, that there is no C compiler installed, so get Visual Studio. Does this make sense, even if I can execute the C command from any directory in the command line?

And what's with the Freebasic version? Must that be one from the time, when the code was created? My actual target is to modify the 2013 engine version and make a game.exe for Windows.

Is it easier to cross-compile the Windows version from Linux? I remember a lot of penguins laughing: "Windows is not for programming."
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

My memories about the c/c++ code are fuzzy.

The more I think about it, the more I think that Visual Studio might only be required for the gfx_directx backend. I might be remembering wrongly though.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Use GCC. Visual Studio isn't supported for compiling game, custom, or any of the other .exes, but is required for compiling gfx_directx.dll. I did make a start on adding support for compiling everything with VS (probably the main roadblock is that SConscript passes lots of gcc commandline arguments).

scons tells you to install Visual Studio on Windows by default if it can't find a C compiler. Really strange that it can't find it. Did you make sure to open a new Command Prompt window after editing your PATH? Unless you edit the PATH using the SET command, it won't affect existing command prompts.

You can also try overriding the path to GCC with "SET CC=c:\mingw\bin\gcc.exe" before running scons.

Does scons print anything else when you run it? Normally it prints something like this:

Code: Select all

>scons game
scons: Reading SConscript files ...
Using target: win32  arch: x86  gcc: C:\mingw\bin\gcc.EXE  cc: C:\mingw\bin\gcc.EXE  gcctarget: mingw32  gccversion: 481  fbcversion: 1040
scons: done reading SConscript files.
scons: Building targets ...
You can have a look at previous versions of articles on the wiki to find out about the compiling requirements at the time. For example, I think this revision is relevant to compiling in 2013.

Note in particular:
FreeBasic 0.23 is recommended, because some features of live previewing (Test Game) are broken in FB 0.90 and later. If you don't care, you can use the latest version of FB.
Versions of the OHRRPGCE from 2013 won't compile with FB 1.00 or later. I think FB 1.00-1.03 could be used with some minor fixes (see svn r6818).
Last edited by TMC on Fri Jul 19, 2019 11:39 pm, edited 1 time in total.
User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Post by Bird »

Oh dear. There are some tripwires to stumble over. I think forget GCC, forget MingW, just install this fat programm called Codeblocks, there is everything on board (attention: there exists also a version without MingW). No version conflicts between MingW and GCC at least. The path would be then something like C:\Programs\CodeBlocks\MinGW\bin (where the "c++" command is located for example).

For compiling the 2013 OHRRPGCE (beelzebufo), Codeblocks 10.05 of 2010(!) which included GCC 4.4.1 worked.
Using Codeblocks 12.11 of 2012 with GCC 4.7.1 results in an error, that has to do with "-static-libstdc++", a command that seems to have undergone changes in between these two GCC versions. It was FreeBasic 0.21.1 of 2010 used for compiling.

My fault was to use a current GCC version of 2018 (who could expect it to be incompatible, too?), that was not even recognised by Scons in the beelzebufo version. The 2012 GCC version was recognised, but gave an compiling error. The 2010 GCC version worked.

What do we learn? Try out all versions in range. In this case, we were three years down from the release of that specific OHR version.

Thank you for helping. Although the way of achieving this feels stupid. Why don't the develpers make a GCC version that is finished and everybody uses that instead of having tons of incompatible updates? That was the case with QuickBasic back in the days, wasn't it?
Last edited by Bird on Sat Jul 20, 2019 3:49 pm, edited 1 time in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Good to hear.

MinGW (Minimal GNU for Windows) is a Windows port of the GCC toolchain. There are also other ports, including MinGW-w64 which I recommend if you want to install a recent version of GCC.

I'm surprised you had problems with GCC 4.7.1. GCC is actually highly compatible between different versions. It's far more stable than FB is. However there are sometimes incompatibilities between different versions of libraries, including some changes to libstdc++ at some point. Problems are typically the fault of something in SConscript.


You said you want to fork the OHRRPGCE? We don't have any guidelines for how to indicate that an .rpg file is for a forked version. Well, we do have a couple pages on the wiki, but they are ancient. I see that beelzebufo was the version that added general.reld to store detailed version info, so there is somewhere to put that information, but it won't make game or custom show any kind of warning. You could set the RPG format version number to something large to make them show a warning (though it will say a newer version of the OHRRPGCE is needed).
Last edited by TMC on Sun Jul 21, 2019 12:52 am, edited 1 time in total.
User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Post by Bird »

TMC wrote:You said you want to fork the OHRRPGCE?
No, not for a public release of everything. The only target (at the moment) with all this compiling business is to remove the playing time from the loading screen (but not in general). This shall then be the Game.exe for my game, but nothing else. The .RPG file will stay the same. If I keep improving on playing with the source code, maybe my Game.exe gets more enhancements.

Thanks to James for answering that in a PM, the function "picksaveload" in menustuf.rbas and subfunction "picksave_draw" will be the places to look at for that problem of removing the time from the loading screen. Thought that was too specific to ask it in public (what a stupid thought).
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

Eventually I hope to make the save/load screen more customizable as a built-in feature, but for your purposes, the method you have chosen probably is the quickest way to get what you need.
User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Post by Bird »

The good OHR developers have already come up with their own loading screens. The variety of loading screens wasn't the key seller for the OHR, but neither was its lack of that an obstacle. Well, maybe not so if you have a phobia for clocks and time data...

Another question has arisen from the compiling task. The file size of the newly compiled Game.exe is 1,54 MB (made with scons debug=0), however the original beelzebufo Game.exe was bigger with 1,66 MB. Both operate well, but did something go missing? There was only one little code line excluded! What are the original compiling options, that you use for the release builds?
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

I don't remember what compiling options we used for beelzebufo. That may make the difference, but a different freebasic version could also produce code with a different size. I believe there are also optimization options, but I don't remember what they are off the top of my head.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

If you're compiling a recent version of the engine, you get a release build with "scons release=1 pdb=1" (which is currently equivalent to "scons gengcc=1 debug=0 pdb=1"). But in 2013 scons didn't take those options, looks like we used just "scons debug=0" back then. Adding gengcc=1 should reduce the filesize, as well as running much faster. pdb=1 also reduces the size.

Yes, differences in GCC and FB version will also change the file size, possibly dramatically.

I've noticed that the .exes compiled on James' machine are far larger than mine, currently an absurd 1.5MB larger (game.exe is 3979562 vs 2489436)! The difference is apparently that some unused parts of the C++ library are being included in the .exes and not stripped on his machine, but I don't know why.
Last edited by TMC on Sun Jul 21, 2019 11:56 pm, edited 2 times in total.
User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Post by Bird »

Modifying the source is really a challenge! But asking might save time for searching.... so for example when I want to use something like this from menustuf.rbas, which displays the level stat in the loading screen:

Code: Select all

lev(i) = readglobalstring(43, "Level", 10) & " " & pv(i).leader_lev
I understand that this first writes "Level" (or how that is called in the game's interface) with readglobalstring, then a space, and then the actual level with pv(i).leader_lev.

That last thing is defined in savegame.rbas:

Code: Select all

pv.leader_lev = h."lev"
pv.leader_lev = pv.hero(o).lev
Now what would be if that variable shouldn't carry the leader's level, but his total experience points instead? What would I use instead of "lev"? Is there anything pre-definied already for the total experience points?
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Hint: a shortcut for working out how to read or write data is to examine the code for the script commands that achieve the same thing, if there are any. In your case, the "total experience" or "experience to next level" commands:

Code: Select all

 CASE 269'--total experience
  IF valid_hero_party(retvals(0)) THEN
   scriptret = hero_total_exp(retvals(0))
  END IF

 CASE 271'--experience to next level
  IF valid_hero_party(retvals(0)) THEN
   scriptret = gam.hero(retvals(0)).exp_next - gam.hero(retvals(0)).exp_cur
  END IF
I don't know whether you want the total experience (start from level 0), or the experience the hero has gained to the next level (starting from the previous level). Assuming you want total experience, you can see that it's calculated by a function, not actually stored in the hero data (gam.hero(party slot)). So you need to look at the definition of that function:

Code: Select all

FUNCTION hero_total_exp (byval hero_slot as integer) as integer
 RETURN total_exp_to_level(gam.hero(hero_slot).lev) + gam.hero(hero_slot).exp_cur
END FUNCTION
(This is how the function looks in Beelzebufo, not Fufluns)

So you need the leader's level, which is already loaded into pv by SUB new_get_save_slot_preview, and their exp_cur (experience gained to the next level since the previous level), which isn't.

exp_cur is loaded like this in SUB gamestate_party_from_reload:

Code: Select all

       .exp_cur = slot."exp"
pv is a SaveSlotPreview, the definition of which you can find in savegame.bi. You could just add "leader_total_exp as integer" to the TYPE SaveSlotPreview in savegame.bi and calculate it inside new_get_save_slot_preview. Below

Code: Select all

     pv.leader_lev = h."lev"
in that function add

Code: Select all

     pv.leader_total_exp = total_exp_to_level(h."lev") + h."exp"
Last edited by TMC on Thu Jul 25, 2019 1:39 pm, edited 1 time in total.
User avatar
Bird
Slime Knight
Posts: 227
Joined: Thu Jan 26, 2012 2:19 pm
Location: Germany

Post by Bird »

This is fantastic! A lesson to learn about the Freebasic programming language was to ignore the .bas files for editing the source code. Unfortuneatly when searching through all source code files with Notepad++, you get a lot of double results from .rbas and .bas files which led to quite some confusion.

But there is one double result I have to ask about in "savegame.rbas". There is the subfunction "old_get_save_slot_preview", where we have

Code: Select all

pv.leader_lev = pv.hero(o).lev
.
Why didn't I had to build a similar line for "pv.leader_total_exp" in that subfunction? It did compile without!
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

old_get_save_slot_preview is only used when you are previewing a save slot in the old .sav format. That code doesn't get run when you are previewing a save slot that is in the .rsav format
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

The source code is a mix of .rbas and .bas files. rbas is RELOADBasic, our extension to FreeBASIC. .rbas files are processed to .bas files by reloadbasic.py, while other modules are only .bas, with no .rbas file. Generated .bas files are put in the build/ directory away from all the original source code so that there are no confusing double results when searching files.
However, I see that the build directory was only added in 2014. Beelzebufo was a long, long time ago, so you have to put up with things like that which we've already fixed.
Last edited by TMC on Fri Jul 26, 2019 12:08 am, edited 3 times in total.
Post Reply