Disappointed

Talk about anything related to Legend of Grimrock 2 here.
User avatar
Drakkan
Posts: 1317
Joined: Mon Dec 31, 2012 12:25 am

Re: Disappointed

Post by Drakkan » Tue Apr 21, 2015 8:19 pm

minmay wrote:
Drakkan wrote: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 :/
Breath from the unpromising waters.
Eye of the Atlantis

User avatar
Isaac
Posts: 2981
Joined: Fri Mar 02, 2012 10:02 pm

Re: Disappointed

Post by Isaac » Tue Apr 21, 2015 8:54 pm

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
Posts: 2689
Joined: Mon Sep 23, 2013 2:24 am

Re: Disappointed

Post by minmay » Tue Apr 21, 2015 9:27 pm

Drakkan wrote:
minmay wrote:
Drakkan wrote: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.
Isaac wrote:Isn't 64 bit slower?
no
Isaac wrote: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.
Grimrock 1 dungeon
Grimrock 2 resources
I no longer answer scripting questions in private messages. Please ask in a forum topic or this Discord server.

User avatar
petri
Posts: 1917
Joined: Thu Mar 01, 2012 4:58 pm
Location: Finland

Re: Disappointed

Post by petri » Tue Apr 21, 2015 9:29 pm

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
Posts: 863
Joined: Sat Apr 21, 2012 9:57 am
Location: Germany

Re: Disappointed

Post by Zo Kath Ra » Tue Apr 21, 2015 10:10 pm

petri wrote: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?

User avatar
Isaac
Posts: 2981
Joined: Fri Mar 02, 2012 10:02 pm

Re: Disappointed

Post by Isaac » Tue Apr 21, 2015 11:29 pm

minmay wrote:
Isaac wrote: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? :mrgreen:
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.

User avatar
Dr.Disaster
Posts: 2848
Joined: Wed Aug 15, 2012 11:48 am

Re: Disappointed

Post by Dr.Disaster » Tue Apr 21, 2015 11:49 pm

Isaac wrote:
minmay wrote:
Isaac wrote: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? :mrgreen:
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
Posts: 2689
Joined: Mon Sep 23, 2013 2:24 am

Re: Disappointed

Post by minmay » Wed Apr 22, 2015 12:56 am

Isaac wrote:
minmay wrote:
Isaac wrote: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? :mrgreen:
Umm... What do you think "64-bit processor" means? The registers are 64 bits wide, not 32.
Grimrock 1 dungeon
Grimrock 2 resources
I no longer answer scripting questions in private messages. Please ask in a forum topic or this Discord server.

User avatar
Isaac
Posts: 2981
Joined: Fri Mar 02, 2012 10:02 pm

Re: Disappointed

Post by Isaac » Wed Apr 22, 2015 1:18 am

minmay wrote: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
Posts: 467
Joined: Sat May 05, 2012 2:24 pm

Re: Disappointed

Post by badhabit » Wed Apr 22, 2015 4:14 pm

Dr.Disaster wrote:
Isaac wrote: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/

Post Reply