Advice sought - porting game engine to 64 bit.

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Post Reply
User avatar
chaosavy
Silver Sponsor
Silver Sponsor
Posts: 573
Joined: Mon Jun 15, 2009 8:29 pm
x 59
Contact:

Advice sought - porting game engine to 64 bit.

Post by chaosavy »

Hey guys - I'm the dev behind Void Destroyer 1 and 2.

Link to VD2 -

It's been a amazing ride with game dev, and I couldn't have gotten here without Ogre and it's community. The reason I was able to get so far was there were amazing free and open source sources I could use to help me make a game. Without this I'd probably give up and Void Destroyer 1/2 wouldn't exist. To make a long story short - I'm very weak on the behind the scenes elements as I'm self taught and my goal has always been to make games versus to learn how to make games (if that makes sense - learning came with it, but it wasn't the primary goal). When I started - I went from very basic knowledge of programming to making a game, and only really learning what I needed to know as I hit my next obstacle.

So here I am years later with a outdated 32 bit game engine and components.

Anyway - since releasing Void Destroyer 2 - my goal for future projects is to get the game engine to 64 bit. I've ran into some issues which I believe to be due to running out of memory. In addition I want to take advantage of newer versions of Ogre for speed and improvements (though this is a secondary goal).

So I'm looking for advice -

I'm currently using -

Ogre 1.9
CEGUI 0.7.9
Bullet Physics 2.82 (using btOgre)
Open AL 1.1 (using OgreOggSound)
Particle Universe 1.6 (I think this might be a big issue...)


With my primary goal of getting to 64 bit - can you offer me some advice?

With my secondary goal of getting to newer versions - can you offer me some advice?

thanks

Paul
Visit http://www.VoidDestroyer.com to check out my space sim project - Void Destroyer

paroj
OGRE Team Member
OGRE Team Member
Posts: 1119
Joined: Sun Mar 30, 2014 2:51 pm
x 402
Contact:

Re: Advice sought - porting game engine to 64 bit.

Post by paroj »

CEGUI was ported to Ogre 1.10+. See their "v0" branch. I also updated all the remaining plugins you mention for Ogre 1.12 and you can find them here
https://github.com/OGRECave

Also most Ogre applications are built as 64bit nowadays, so there should be no problem. Did you run into anything specific here?

I think the largest obstacle with upgrading will be going from CEGUI 0.7 to CEGUI 0.8 as they changed API and file format there.

loath
Platinum Sponsor
Platinum Sponsor
Posts: 167
Joined: Tue Jan 17, 2012 5:18 am
x 15

Re: Advice sought - porting game engine to 64 bit.

Post by loath »

1. upgrade the 32 bit game to the latest 32 bit libraries before porting to 64 bit. (you're going to get a huge performance boost on ogre 1.12+). this way your game still runs as you upgrade each piece individually.

2. if you don't already have a feel for what's taking up memory, i'd at least spend a little time investigating. it may be that your game has a huge scope so you have a ton of assets. it's still worth looking into. are you using dds with texture compression? (if not this can waste a ton of memory)

3. once you're happy with the latest libraries, i don't think porting to 64 bit will be much trouble. most of your code should compile as-is from 32 to 64 bit. most basic types are the same (float, int, etc) but pointer sizes are 2x. so if you're using reinterpret_cast or making assumptions on pointer arithmetic (ex. that it's 4 bytes instead of 8 ) then you'll need to fix these. the compiler will help with some and the debugger the rest :). porting to 64bit shouldn't be that bad.

User avatar
EricB
Gnome
Posts: 319
Joined: Fri Apr 09, 2010 5:28 am
Location: Florida
x 180
Contact:

Re: Advice sought - porting game engine to 64 bit.

Post by EricB »

I ported GearCity over to 64bit a couple of years ago in prep for OSX shitcanning 32-bit. I also did the hassle of bouncing my OSX carbon code to cocoa and moving to CEF from Berkelium. Most of those pains were Apple induced and had nothing to do with Ogre.

The move to 64-bit is quite easy for Windows and Linux. I suggest bouncing up to at least 1.11, (Possibly 1.12). There will be a couple of things you'll have to change, but your compiler will catch it, you'll look it up here or on google, and then copy and paste your fixes to API breaks.

I did run into a few issues with changes to the resource management system, but I just reverted the function to 1.7 code to get the behavior I expected.

I did not upgrade renderer systems. Since I am the only person in the world unfortunate enough to be using QuickGUI in a shipped product, I wasn't able to bounce it up to OpenGL3 within my timeframe. The lack of Fixed Function Shaders broke it, and I couldn't get the RTSS to generate emulated ones for OpenGL3. So I am still using OpenGL1/2 and DirectX9. So your mileage may vary changing rendering engines, I didn't test em.

I still maintain my 32-bit builds on older versions of Ogre. The repo works out of the box on all OSs and Arches. It does take a few defines though, but nothing crazy.

I do recommend keeping the 32-bit build around if you're using Visual Studios (which I imagine you are, since it's a requirement for SteamSDK). You're going to run into users with horrific system setups, and they're likely to get "The Application cannot be started correctly (0xc000007b)" error codes when their machine tries to use 32-bit VS redistributables instead of 64-bit ones. Sadly, most users can't figure out how to fix it, even with directions. In which case, you just point them to the 32-bit build in the Betas branch as an option.

I upgraded from customized (backported bug fixes I needed) Ogre 1.7.1 in Windows, 1.7.4 in Linux, and 1.8.1 in OSX.

Here are my libs and frameworks:
Ogre3d
QuickGUI
OgreOggSound
Berkelium/CEF
SQLite
OIS
SDL (Linux)
GLFW (OSX)
AdvanceOgreFramework

And then the standard libs Ogre requires. There isn't any API breakage from the ~2014 ones I use for the 32-bit build and the 2018 64-bit ones. Although, Freetype has change font hinting sizes, so fonts are 2px bigger in later versions...


P.S. One of these days I will buy and play your games. When I am done making my games... I still maintain, you need to bundle 1 & 2 and give a 10% discount. Dunno why you haven't.
Image

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4340
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 877
Contact:

Re: Advice sought - porting game engine to 64 bit.

Post by dark_sylinc »

It's as everyone already described.

Porting effort is minimal, unless you depend on a particular library (usually without source code access) which doesn't have 64-bit libs (or for some reason it's full of bugs in 64-bit)

If you hardcoded some assumptions e.g. like assuming that sizeof(size_t) == 4 or sizeof(int) == whatever, then of course you're gonna have a bad time.

Aside from that, there may be the ocassional pointer truncation bug, for which you can use OS-level tools or simple tricks to help you force allocations to be always above 4GB, which will trigger pointer truncation bugs immediately.

Raymond Chen has two articles about it. MEM_TOP_DOWN is a sure way of testing, although it's a system-wide setting.
Application Verifier also has some settings about it.

I recall macOS having some similar tools, but I forgot exactly where.

Cheers

Post Reply