New release posted here:
Engine Test Build - Mythruna Wiki
Release notes here:
20110220 Release Notes - Mythruna Wiki
Lot’s of good changes in this past week. Hopefully the engine feels tighter.
Note: I apologize to anyone doing extensive building on older machines as sometimes there is a noticeable pause when placing blocks and I still haven’t tracked the issue down. Lots of things I can potentially fix to help but the time seems to be going to counter intuitive things.
I’m going to follow up with a link to one of my test areas with some buildings. Now that the game has a database, you can drop this in on top of yours to get the buildings.
Also note: the new clip distance defaults to a shorter distance than the previous build. F12 cycles through the options and you can see the current value in the HUD.
For fun, I zipped up a portion of my own Mythruna database that has some of the buildings I’ve been playing with.
You can download it here.
The easiest way to make sure to get it right is to run the game and add or remove a block from anywhere near where you start. This will create the database. Then just unzip the above linked zip over top of your mythruna.db directory. Hopefully it’s obvious how everything lines up… overwrite any existing .leaf files.
If you run the game again then you should have the standard carved out flat area from the previous build’s starting location… and it should have a couple buildings.
Just delete your DB if you want to go back to virgin territory.
I suggest to use JVisualvm, then you can see wich methods are eating the time.
Hi,
tested your build on a current MBP with OSX 10.6 and GF330M. I encountered a peculiar bug concerning water visibility. At certain angles the water appears and at others the water disappears again. Two shots to visualize it:
I only moved minimally between the two shots…
Cheers
Nope, it stands still.
It’d looked like some users with ATI cards were having trouble with the water, also. I may have to put together a smaller material test to isolate issues. This stuff is very frustrating.
…I’d hoped that at least the .vert shader that animates the water would be working. Though that may be a thread for me to pull on.
EmpirePhoenix said:
I suggest to use JVisualvm, then you can see wich methods are eating the time.
This kind of topic may deserve its own thread but we'll see. ;)
I may try that tool. I've done some other random profiling using the built-in profiler and I've littered various parts of my code with nanoTimer calls just to keep track of things. However, some time sinks seem to confound normal analysis.
For example, I add/remove a lot of stuff from the scene as the player walks around. When old stuff falls off, I detach it. When new stuff comes into view, I attach it. I do this in little bits per update call trying not to "break frame". Every now and then, though, an add or remove will take 20 times longer than any other time, especially on these slower machine combinations. I need to look into whether geometry size is a contributing factor but walking the same paths through the world very rarely produces the same bumps. Also, editing blocks in a local 32x32 area (which regenerates the geometry each time a block is added or removed) will sometimes hang similarly. I need to look at whether I can see the same thing by simply adding and removing the same block... which would eliminate certain factors as culprits (though something did just occur to me I can also look at there).
I suspect there is something going on deep within JME that I'm not taking into account. Some reshuffling or other processing that happens on blocks... or some other memory management hit (since this is similar to when the GC kicks in). I don't even know where or how to ask questions like that so it may require some self-exploration. :)
Thanks for the tip, though. I'm willing to try almost anything at this point. :)
Hi,
if those really happen mostly when attaching/detaching the chance that it’s GC is quite high. You could try to increase the heap size of the JVM and see whether those bumps are less frequent then. This would be a good indicator.
To really rule out GC issues, go to http://java.sun.com/developer/technicalArticles/Programming/GCPortal/ and see how you can log GC actions. In your case with all those random data creations/destructions you would’ve looked into it sooner or later anyway 
And fix this water, I wanna play! 
Cheers
98% sure it isn’t GC in this case since the heap max is set to 1 gig and the heap is still rising rapidly at these points (it happens when I’m still only using 200 meg). I do know about GC logging but hadn’t considered it yet for those reasons. All of my own objects are cached and tightly managed so it might be down in the geometry. (presuming I haven’t overlooked some other issue in my own code.;))
If direct memory as is used by the VertexBuffers is managed in a similar way to regular heap then that’s probably my culprit. Upping the size there would only delay the inevitable, and technically have the potential to make it much worse. I will do some research on direct memory buffers. There may be no good way to resolve this issue.
@Dodikles, looking closer at your screen shot, it is not only the water that is messed up. The sides of the grass-topped blocks seem to be messed up also. They should mostly be just like the plain dirt blocks but with a little tuft of grass at the top.
Ugh… I don’t know if the two issues are related or not.
Yeah, haha I was wondering myself why the game looked so strange in the first place 
If you need further OSX testing, tackle me
@Dodikles That would be super cool of you.
In the mean time, if you could be so kind as to see if placing the “rock wall top” blocks exhibits a similar issue to the grass blocks? Like the grass is similar to dirt, the wall top should be similar to regular rock wall but with slabs of stone on top.
Actually, if you have a few minutes, finding an open area of ground and placing one each of the first 12 (or so) block types, spaced out, and then sending me a screen cap could be super helpful. I’m trying to narrow down the common conditions between the failing materials so knowing which ones are right and wrong would be helpful.
…you know, I spend so much time trying to come up with pretty screen shots, I should spend some time coming up with at least one or two that shows how the normal stuff is supposed to look.
I was able to run this build, all seems good so far 
did you add a bit more bloom in this version? Looks good on my n220 machine.
Thanks for testing again. Hopefully it is getting more ‘playable’ with each new revision.
lwsquad said:
I was able to run this build, all seems good so far :) did you add a bit more bloom in this version? Looks good on my n220 machine.
No, but the fog settings may have changed slightly when I synched it with the clip distance. It used to be that even though the clip was 160 meters that fog was 128... and 1.0 intensity. i synched it to be the same distance and upped the intensity to 1.1 or something to match. It may change the ramp a little.
Does it look better or worse to you? Or neither? :)
Also note, the clip needs to be extended (by hitting F12 twice) to 160 for it to be similar to the last build. I think next time I will default it to far clip.
It looks good, maybe a bit too bloomy, but that just my opinion but it does look good! I’ll try the F12 clip setting.
The bloom goes up pretty high at certain times a day to try to make the ‘golden hours’ glow a little more. And with the clip distance set short, everything is more glowy. I probably need to synch bloom to clip/fog distance.
…endless tweaking… endless tweaking.
Screen shot here:
pspeed said:
The bloom goes up pretty high at certain times a day to try to make the 'golden hours' glow a little more. And with the clip distance set short, everything is more glowy. I probably need to synch bloom to clip/fog distance.
...endless tweaking... endless tweaking. :)
Ahh that makes sense :) It does look good, I haven't had a chance to let it cycle much time, so in the vision of the "golden hour" that I might be in does fit the scene well :)