DruggedBunny

Forum Replies Created

Viewing 15 posts - 226 through 240 (of 347 total)
  • Author
    Posts
  • in reply to: Removing from Stack/Stack Assert? #12823

    DruggedBunny
    Participant

    Interesting read! I was wondering why it worked with lists (in Blitz), and noticed they were also ‘failing’ in mx2 the way stacks do. (I’d tried switching the above code to a list.)

    The pb.Destroy () / boxes.Clear () option works well here for the Space-bar hit, but what would be the best way to handle removing an object mid-iteration, as UpdateBoxes () — minus boxes.Remove (pb) — still crashes, obviously for the reasons you’ve explained, since it’s not emptying the whole stack like Space does.

    Thinking about it, I suppose a stack isn’t the best solution for this scenario, ie. removing arbitrary objects from the middle of a collection, since stacks are all about adding/removing at the top of the stack, but what would be better here?

    (I just used a stack because I gather they’re quicker than lists!)

    That stack-top popping-copying thing is pretty cool, but I guess maybe a map could be a better overall solution?

    in reply to: Removing from Stack/Stack Assert? #12818

    DruggedBunny
    Participant

    Hmm, thanks, nerobot. It’s quite complex, but seems to do the job anyway. I’ll try understand it!

    in reply to: Struggling with Struct arrays #12789

    DruggedBunny
    Participant

    Cool, I had to not-New it, too (suspected so), but it’s working now with:

    Thanks!

    in reply to: mojo3d physics… why am I not colliding? #12785

    DruggedBunny
    Participant

    This is pretty cool, but I can’t figure out how to delete/remove RigidBodies… see KeyHit (Key.Space). I’m trying to clear my stack of PhysBoxes (containing RigidBody and Model references), but they always remain! Perhaps not implemented yet? There is code that looks intended to work in RigidBody.OnDestroy…

    Rotation doesn’t work, either, as the RigidBody doesn’t pick up the Model’s rotation, which I suppose it to be expected, though it picks up position. Not sure how this should be handled…

    in reply to: mojo3d physics… why am I not colliding? #12784

    DruggedBunny
    Participant

    Sorted this — turned out to be the order in which I was declaring the Boxf parameters at start of PhysBox.New ()!

    Was:

    … but should be:

    in reply to: Struggling with Struct arrays #12783

    DruggedBunny
    Participant

    This revised version gives me “Translator.Trans() Internal Error”:

    This says…

    Turns out that’s the error the first version gave, it was just that the output was hidden.

    I get various different internal errors depending on what I do in Main with that last code…

    This builds OK, but obviously does nothing:

    New’ing produces a different error:

    Output for this is:

    … and adding the sizeof line gives the “Translator.Trans() Internal Error”:

    Tried without New as well, but assume that is needed… same Trans() error anyway…

    in reply to: Struggling with Struct arrays #12772

    DruggedBunny
    Participant

    OK, will give that a shot later. Didn’t even realise there were W versions of Win32 structs!

    in reply to: mojo3d physics… why am I not colliding? #12771

    DruggedBunny
    Participant

    Thanks, Mark — thy are both 1 at the moment, but aren’t colliding in this demo. Will be playing again tonight though, no doubt.

    in reply to: Struggling with Struct arrays #12763

    DruggedBunny
    Participant

    Oh, PROCESSENTRY32 — Short was my best guess for a TCHAR!

    MSDN

    in reply to: 3d – CreateTerrain is in yet? #12744

    DruggedBunny
    Participant

    It is.

    in reply to: Simple Win32 API call attempt #12732

    DruggedBunny
    Participant

    Got this working using Diffrenzy’s HWND hack here.

    I did try Aliasing it as Void Ptr, which I thought would work, as HWND is a HANDLE, which is a void pointer according to Windows Data Types

    in reply to: Simple Win32 API call attempt #12719

    DruggedBunny
    Participant

    This no longer builds here (your code), gving a load of output I don’t really understand! Just ran into it while trying to do something else (around 6 hours trying to debug Ted2Go debugger crashes!)…

    I’m on latest dev, though last one fails too.

    in reply to: Should a mojo3d app be hogging 100% CPU? #12653

    DruggedBunny
    Participant

    OK… that looks to be it — with SwapInterval=1, cubes runs at around 4-5% total CPU now (that would be maybe 20% on a single CPU), obviously much better, though if nothing’s going on I’d have thought it’d be near zero. Maybe that’s mostly the driver stuff, though? [EDIT: It is… ]

    I did find a cool little profiler while trying to determine which thread was doing the most work:

    Very Sleepy CS

    It’s pretty cool — you highlight the process of interest, then either profile all threads, or the one(s) you’re interested in, leave it a few seconds and stop it, then you get a list of functions that are being called, and for how long (much better function list if you download the symbols first and run the game in debug mode).

    Kinda hard to make much practical sense of, but running in release mode, then just highlighting the cubes process and watching the thread usage is kind of interesting (see image vsleepy.jpg). It shows WaitForSingleObject as a key busy-function (right-hand pane), and if I profile that, I get vsleepy2.jpg, which seems to suggest DrvValidateVersion as the caller, and a quick Google says that’s part of the driver.

    I checked the only other high-usage thread showing in vsleepy.jpg — everything else being basically 0% — and that’s also driver-related (DrvPresentBuffers and DrvValidateVersion), so it seems all of that CPU usage is down to Nvidia.

    Anyway, that has basically solved it, way better than before, been running for a while now and fans are much quieter!

    Well sorted!

    Regarding the 1060, it’s a pretty good card for 1080p stuff, runs most things very well. Does 4k, but you have to turn most things down for that. Just saw on PCGamer that it’s currently the most-used graphics card on Steam!

    Oh, I had vsync set to use app setting already… however, just tried commenting out SwapInterval=1 in cubes, and it does do the lower CPU usage, so sounds like that’s actually working! Which doesn’t explain last night’s results/screenshots… er… ?

    Treat as resolved for now!

    in reply to: Should a mojo3d app be hogging 100% CPU? #12628

    DruggedBunny
    Participant

    Being the bearer of bad news, I apologise… but cubes shows higher CPU here (actually more than 1 CPU, somehow, average about 26%, seen 28%), while the code at the top shows almost 0!

    It was typically 16-17% before, which at least makes sense for full 1 x CPU usage. Perhaps it’s now somehow using another couple of threads?

    EDIT: Er, it’s using way less threads, but more CPU… see attachments!

    Both are in Release mode.

    Perhaps cubes is doing heavy stuff in main loop, though it doesn’t look like it (not checked code, gotta go to bed for work!).

    The changes obviously do something really weird with threads…

    Just re-run both current and last develops to check again, definitely per screenshots, ie. old has 16-17% (1 x CPU) and new has 26-27% (2-3 CPUs), with old having ~twice as many threads! Both in Release.

    Attachments:
    in reply to: Should a mojo3d app be hogging 100% CPU? #12627

    DruggedBunny
    Participant

    Just building, will post before hitting the hay!

Viewing 15 posts - 226 through 240 (of 347 total)