Fingolfin

Ah, I overlooked a cauldron... got it

So I got this quest "Medici Errands" in "Old Cinnabar Works", and also supposedly there are resources there. I cleared out all I could reach, but inside the barracks, there is a locked door, and I have no idea where to find a key. Any pointers? (Sorry, the topic should be titled "Can't complete ...", not "Can't enter ...", as I can enter it, just not all parts of it.)

Thank you, Jeff, for making wonderful games 🙂

It would still be nice to learn what exactly is new?

Jeff, first off: nothing could be farther from me than a refund. I love that game far too much, like I love all your other games (like many people here on the forum, I've been with your software since I was a teenager and discovered Exile :-). So, please take our complaining as a wish to see what we love become even better :-). (OK, well, I can of course only speak for myself, but that's genuinely the impression I have from everybody else in this thread). That said: You don't even have to mess with SDL2 itself for an immediate improvement. As I explained: Just locate your call to SDL_PollEvent, and if it returns 0 to indicate that no event was handled, just call SDL_Delay(1). Of course it may be possible to do something better, but without seeing the code, I can't comment (I would be happy to help with that, though, if desired: If you send me a copy of your main game loop (not the rest of the code), I could possibly make better suggestions based on that. I'd be happy to sign an NDA or anything for that, too.) The other suggested changes also don't require you to mess with SDL internals: - change your call to `SDL_Init` to use slightly different arguments - change your call to `SDL_CreateRenderer` to use slightly different arguments - switch to a recent SDL2 version for Mac, that was compiled with optimizations on; e.g. as available here https://www.libsdl.org/download-2.0.php) Unbound Servile has a point though, the design of the SDL2 event handling is not quite the best (in fact, even in Classic MacOS, they started out event polling, using GetNextEvent, and a major improvement over that for the MultiFinder was the addition of WaitNextEvent -- 30 years ago; SDL2 sadly is falling back to the old polling model. In its defense, though this is the result of a compromise between many, many different platforms and what their needs are (I should mention that I used to be a contributor to SDL1, many, many years ago, but it's been a long time since I worked on it or even used it, so some of what I say here may be out dated. I am pretty sure that if one talks to the SDL maintainers, like Sam Lantinga and Ryan C. Gordon, who are doing an outstanding job on supporting it across many platform, then they would be willing to accept patches to improve the situation regarding event handling, or even work on some improvements themselves. In fact, this was discussed like 2 years ago on their mailing list / forums, so for some background info, you can read up here: https://discourse.libsdl.org/t/blocking-sleep-in-sdl-waiteventtimeout/23255/12 ) Anyway, back to Queen's Wish: Should you be willing to mess with SDL itself and compile your own version, you could try the following slightly hackish solution *instead* of inserting SDL_Delay calls as I suggested above: In file src/video/cocoa/SDL_cocoaevents.m change line 431 from this: NSEvent *event = [NSApp nextEventMatchingMask:NSEventMaskAny untilDate:[NSDate distantPast] inMode:NSDefaultRunLoopMode dequeue:YES ]; to this: NSEvent *event = [NSApp nextEventMatchingMask:NSEventMaskAny untilDate:[NSDate dateWithTimeIntervalSinceNow:0.001] inMode:NSDefaultRunLoopMode dequeue:YES ]; Here we insert a wait of 0.001 seconds = 1 millisecond. You can of course experiment with this and try e.g. 0.01 or 0.005.

That question was cut off, so I am not completely sure what you wanted to ask. But anyway, sleeping for a short duration is fine, and in fact standard with SDL apps. I also noticed that considerable time is spent on querying for joysticks -- Jeff, looking at the disassembly again, it seems you are passing SDL_INIT_EVERYTHING tp SDL_Init, which include SDL_INIT_JOYSTICK and SDL_INIT_GAMECONTROLLER. Replacing that with "SDL_INIT_TIMER | SDL_INIT_AUDIO | SDL_INIT_VIDEO | SDL_INIT_EVENTS" might be a good idea. Also, perhaps turning on V-sync would help (add SDL_RENDERER_PRESENTVSYNC to the flags passed to SDL_CreateRenderer).

I should actually clarify: the 10% are for idling in the background (actually, it's more like 8-9%). When idling in the foreground, it's 23-24%. When doing something, this goes up to 40-50%, depending on what kind of "action" is going on. Which is fair enough, of course.

Oh come on! You wrote that engine, and the problem is caused by that engine, not the design of the laptop fans. The game shouldn't be using 100% CPU time, esp. when idling. So as a quick proof of concept for my suggestion above, I took out my disassembler to hack the SDL2 copy bundled within Queen's Wish, to see if I could fix the issue. Luckily, it seems the SDL2.framework you are using was compiled without optimizations (which, by the way, is another thing where perhaps some performance is lost?). But for me that was perfect, because that gave me ample opportunity to replace useless instructions in the code with alternate code. First, I edited SDL_PollEvent (or rather, SDL_PollEvent_REAL) to call SDL_WaitEventTimeout with a timeout of 1, instead of 0 (basically I replaced two useless mov instruction with NOPs, plus "inc esi"). That resulted in a Queen's wish that only took 2% CPU time, but the mouse was super sluggish. Turns out that SDL_WaitEventTimeout(_REAL) always sleeps for at least 10 milliseconds, which apparently is a bit long. So I located the call to SDL_Delay in there, and replaced the "mov edi, 10" by "mov edi, 1". The result: an apparently fully function Queen's Wish binary that "only" takes up 10% CPU time when idling. Granted, that's still not ideal, but sufficient to keep my mac nice and cool, and also use up much less battery power. I bet one can do better, but without knowing anything further about your game's main event loop, I can't say how (OK, I could now reverse engineer *that*, but while that is a fun thing to do, I'd rather use the time to play some more Queen's Wish ;-). Of course you could now simply perform the same changes, which would require using a modified SDL. But since you have access to the source code of Queen's Wish, there are muchbetter ways: Basically, when calling SDL_PollEvent, if it return 0 (= no event was found), then call SDL_Delay(1). There are various possible variations of this, of course, depending on how your main game loop looks like; also, if you determine that even a delay of 1 millisecond is a bit too much, one can also sleep with nanosecond resolution, but unfortunately SDL does not expose a portable API for this, so it'd require some "#ifdef MACOSX" style of logic (not too horrible, though).

Well, that may be, but it's not really a nice situation, is it? I mean, I love these games, but the graphics and game play logic hardly should require that kind of CPU power. As a programmer, my impression is that something is doing a busy wait instead of only using CPU resources when action is needed (i.e., an event driven game loop). And indeed, looking at a sampling of the Queen's Wish process, almost all the time is spent inside SDL_PollEvent. I wonder if Jeff ever considered using SDL_WaitEvent instead, or perhaps SDL_WaitEvenTimeout with a timeout of, say 10 milliseconds -- that allows for 100 Hz game updates, which should be plenty?

So I've been tremendously enjoying Queen's wish so far, but one thing is really bugging me: While playing it, one of my laptop's CPU core is maxed out at 100% load. This causes the machine to heat up, the fan spins up, and it gets *loud*. This is on a MacBook Pro 15" (2018, with hexacore i7 at 2.6 Ghz; 32 GB RAM; Radeon Pro Vega 16), running macOS 10.14.6 . It happens both with the Steam version, as well as the DRM free standalone version. Anybody else having this issue?

Thanks!

Hi there, could somebody enlighten me regarding the difference between spellcraft and magery? The descriptions sounds pretty similiar, and I now have the option to increase both on my character. But not knowing the difference doesn't really make this easier. BTW, is there any reason to increase the mage/priest spell levels beyond 17 (which according to the manual is the level of the highest priest/mage spells).