Disappointed

[Drakkan]

from main campaign perspective I can only agree - optimization should be quite ok and I know AH improved it a lot. However from modder perspective it just sucks. Currently we are limited not only in size of the mod, but also from using custom tilesets etc... and this is confirmed reality, not just complaint

What do you mean?

See Dr.Disaster answer. I know you can say this is not AH mistake and I understand I cant blame them for it, but still from my view this is bad optimalization as the game should count with something like this and it should be 64-bit windows world, not 32-bit :/

[Isaac]

Isn't 64 bit slower? (Not that it matters in emulation.)
What if the game as designed, doesn't need 64 bit addressing?

There are several apps that ship with both 32 & 64 bit versions. I think that for a game with user mods, it might be in order to offer the same, and simply have the mods flagged internally as requiring the 64 bit version, or optionally they could detect the app version and use substitute content. (Though I think it far better, and easier, to simply upload two versions of the mod, and let the player pick the best one for them.)

[minmay]

from main campaign perspective I can only agree - optimization should be quite ok and I know AH improved it a lot. However from modder perspective it just sucks. Currently we are limited not only in size of the mod, but also from using custom tilesets etc... and this is confirmed reality, not just complaint

What do you mean?

See Dr.Disaster answer. I know you can say this is not AH mistake and I understand I cant blame them for it, but still from my view this is bad optimalization as the game should count with something like this and it should be 64-bit windows world, not 32-bit :/

There is no optimization that would allow your mod to use more than 2 GiB of RAM. I'm not sure how you're even running into a problem with that in the first place, unless you're not compressing your textures or you're importing all standard assets or something.

Isn't 64 bit slower?

no

There are several apps that ship with both 32 & 64 bit versions. I think that for a game with user mods, it might be in order to offer the same, and simply have the mods flagged internally as requiring the 64 bit version, or optionally they could detect the app version and use substitute content. (Though I think it far better, and easier, to simply upload two versions of the mod, and let the player pick the best one for them.)

It's not always as simple as flipping a compiler switch, the code may not be 64-bit clean already. And it would be a compatibility nightmare for mods.

[petri]

Yes, Grimrock is a 32-bit application (on Windows) because the market share of 32-bit Windows OSes was significant at the time when the decision was made. The game was made with 32-bit limitations in mind, so that when all levels are loaded into memory, there is not much memory left.

I'm now working on a new game engine called Shinobi, which is 64-bit only (no support for 32-bit Windows). btw. 64-bit is usually a little bit faster because in 64-bit mode more CPU registers are available.

[Zo Kath Ra]

I'm now working on a new game engine called Shinobi, which is 64-bit only (no support for 32-bit Windows). btw. 64-bit is usually a little bit faster because in 64-bit mode more CPU registers are available.

Grimrock 3?

[Isaac]

Isn't 64 bit slower?

no

If you are passing a pointer that is 64bit wide, are you not passing a pointer address that is twice as long as one with 32bits? Does that not mean that it takes twice as long to pass as an address half that length? What I'm asking is, wouldn't the 32bit address have already been passed at 32bits, while the 64bit address still has 32bits left to go?

It's not always as simple as flipping a compiler switch, the code may not be 64-bit clean already. And it would be a compatibility nightmare for mods.

I didn't think that it was. Though it's true that the apps I had in mind seemed to do so mainly for export compatibility with 3rd party products (like Quicktime).

____________
**I used to like to play Shinobi.

[Dr.Disaster]

Isn't 64 bit slower?

no

If you are passing a pointer that is 64bit wide, are you not passing a pointer address that is twice as long as one with 32bits? Does that not mean that it takes twice as long to pass as an address half that length? What I'm asking is, wouldn't the 32bit address have already been passed at 32bits, while the 64bit address still has 32bits left to go?

As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower.

[minmay]

Isn't 64 bit slower?

no

If you are passing a pointer that is 64bit wide, are you not passing a pointer address that is twice as long as one with 32bits? Does that not mean that it takes twice as long to pass as an address half that length? What I'm asking is, wouldn't the 32bit address have already been passed at 32bits, while the 64bit address still has 32bits left to go?

Umm... What do you think "64-bit processor" means? The registers are 64 bits wide, not 32.

[Isaac]

Umm... What do you think "64-bit processor" means? The registers are 64 bits wide, not 32.

Native.

32 bit machines have 32bit registers.

*The mr.green emote is also a kind of 'tongue-in-cheek'/sarcasm/'yes I went there'/ Swiss army knife of an emote. The [second] post was rhetorical.

[badhabit]

Isn't 64 bit slower?

As long as the CPU uses at least 64 bit in every area (registers, op-code, busses) and therefore does not has to resort to 32 bit operations to emulate 64 bit operation it can't be slower.

Infact, if you take the same CPU with the same ISA and architecture (register number) & die size for 32 & 64bit, the 64bit version will be normally (slightly) slower, due to increased instruction cache pressure due to double sized pointers.

here some benchmarks http://www.osnews.com/story/5768/Are_64 ... es_/page3/