76

(26 replies, posted in Engine)

I am just grabbing gDEBugger to take a look at that tonight. I had a run through Sponza with the profiler, I was getting 6fps so I guess it isn't necessarily the lighting that's causing the slow performance, probably the large amount of polys. I guess this is a reasonable stress test tongue
I will do more investigation into why this might be anyway.

Just a quick question though, where do you think the best place to "pump" the profiler would be? I've got different readings when I put it in different places. For example on Sponza, I get ~300fps if I put it at the end of  MaratisPlayer::LogicLoop, if I put it at the end of the while(true) loop in main() then I get 6fps, and if I put it in draw() then I get 8fps

77

(26 replies, posted in Engine)

I finally got around to switching to gluBuild2DMipmaps and I'm still on about 2fps, so I guess it's not that tongue It's a shame that I really can't profile OpenGL at all to see what might be causing the problem. I'll try taking lights and  things out... see if I can figure it out... based on the fact that I can get a standard simple scene running at 60fps, I should be able to figure out which feature I'm using that's causing the problems...

78

(26 replies, posted in Engine)

Thanks for these smile I'll try and take a look at what it might be.

79

(26 replies, posted in Engine)

Heh, I just realised that the scene was trying to use the standard renderer, so I changed that in the mproj and the scene loads now (well, after about 5 minutes parsing the xml meshs...) and I'm down to... 2fps... and once again, it's not in any profilable part of Maratis, which suggests OpenGL again...

I realise that an Intel GMA 945 netbook might not be the target machine for Maratis, but I think I would like to try and get a reasonable framerate on my netbook.

So continues my trek into profiling and optimising.

First, a couple of things I may be using in the scene that might cause the slowdown. First of all lights. The scene is pretty full with them. I can replace them with pre-generated lightmaps, but I would like for less-useless machines to still use dynamic lights where possible... so maybe having it so you can specify a lightmap, which only gets used in the fixedrenderer, and lights which only get used in the standardrenderer? Next, poly count. I will have to do some profiling where I change the amount of lights in a scene, keeping the polys the same, and then just add more polys, but I think reducing polys is always good anyway. The obvious solution to this would be to add a LoD system, and on less powerful machines (potentially exposable to players via a "detail" slider in a menu) it would use lower polygon models.

80

(26 replies, posted in Engine)

Right. So I feel a bit silly. I got the simple scene, with just a cube, running at more than 4fps. It's actually at 60fps now. Woo!

You were absolutely correct, it was a GL feature that my graphics chip didn't support. In particular it was point sprites... so yeah, the thing that I added for particles. It means I've got to be able to fallback on using billboard sprites rather than point sprites if possible. I will see if I can get it to check whether GL supports point sprites natively before enabling them...

The strange thing is, I've tried to load a more complex scene and I get an infinite update... I guess it's probably something to do with the lighting. I think it would be nice to be able to switch between a standard renderer scene and a fixed renderer scene...

81

(1 replies, posted in General)

This is a bit of a strange question, but what is the easiest way to make Maratis run without a window?

I'm considering using Maratis for a couple of different things, including having a scriptable, automated project build system. For this I would like to have a headless/batch mode. Simply disabling the draw calls in headless mode will stop it rendering, but the window still comes up. As things like MWinContext use MWindow to provide some implementation, I assume just not instantiating the MWindow wouldn't work. I guess making a dummy window with stubbed init/render functions would be the best way?

82

(26 replies, posted in Engine)

But surely if it takes time to wait for the GPU at all, that time would show up on the CPU side? I would assume in something like a flush or swap buffer or something. What it looks like to me is that it's losing the time in between the loops of while(true) somehow... but I'm not sure how that could happen.

I am going to see if I can steal someone's time today to take a look at it, it's probably something relatively simple I'm missing out, but I'm just not seeing it. I would really like to tune Maratis to run a bit smoother, but I can't really optimise blind like this tongue

83

(26 replies, posted in Engine)

I've kept looking at what might be causing the problems here and I am still getting ~200ms missing time which is really confusing as I've tagged the main loop so if anything, it should all fall under that. At one point, I thought it could be maybe a threading issue, but then again, waiting on a thread to complete execution should _still_ show up...

Out of curiosity, I stuck a return in the top of draw() in main.cpp and... I got unprofiled time 1ms, 1000FPS. Moving the return down the function confirmed that it's definitely the render loop that's causing it. I'm still a bit confused why it's not showing up in the profiler at all though

84

(26 replies, posted in Engine)

The only cards I have available to test on are an intel 945 chipset with integrated graphics... and I now have had to downgrade my PC from a 4 year old ATI to a much older ATI because my card burnt out sad Before it did, I seem to remember my PC struggling on Linux, and I definitely had 3D support on there working...

At lunch, I can pastebin all of glxinfo and I can take a look at what the issue might be.
Edit: My glxinfo

85

(26 replies, posted in Engine)

Erm, I'm running linux, so I wouldn't know about DX tongue
I've checked glxgears and get a consistent 60fps. glxinfo gives my version as 1.4, Maratis also claims I have 1.4 support. I also checked that I have direct rendering.

86

(26 replies, posted in Engine)

I just made it cough out the FPS to the stdout. I didn't realise that Maratis only stopped rendering when it didn't have focus, but keeps updating. I get ~4fps when the window has focus, 60+fps when it doesn't. I guess that proves that it's definitely the rendering. Ahh well. That means I either need to kick my netbook into not falling over constantly, or upgrade...

87

(26 replies, posted in Engine)

I've figured out what was going on. The MaratisPlayer constructor called start() which was called a little later in restart(), both of which called MEngine::setRenderer, using MStandardRenderer. A little later the project is loaded and calls MaratisPlayer::changeRenderer. In my case this uses FixedRenderer.

I've changed the default to FixedRenderer for now, and removed the call to start() from the constructor (because it's being called shortly afterwards) everything seems to run fine, and I've lost all calls to Standard Renderer stuff from the profiler. I still have 219ms unaccounted for. I've got no idea where that's gone... the top time now is MObject3d::updateBehaviors (77us) followed by MObject3d::computeChildsMatrices (70us)

I think I'm going to put a debug render in MProfiler to display an FPS in the top right corner of the screen.

88

(26 replies, posted in Engine)

I've just taken a look, and setRenderer is called 3 times. Time to figure out why...

89

(26 replies, posted in Engine)

That's even stranger then... because my netbook doesn't support Standard Renderer... checking through the other things that the profiler is spitting out, I'm getting calls from both StandardRenderer and FixedRenderer... I wonder why that's happening, the project is even asking to use FixedRender

90

(26 replies, posted in Engine)

Done another run at profiling. I have MEngine and MaratisPlayer fully tagged, as well as MContexts and MRenderers. I'm still missing ~300ms somewhere according to the profiler.

However, I did find out that the swap buffer calls are taking 50+% of the time, so I guess it is the rendering that's taking a while. That's sort of disappointing because it means that it's unlikely I can fix it tongue

It's just occured to me that I'm flushing the profiler once every logic loop. Maybe if I do it at the end of the while loop in main... yeah that gave a totally different log. I'm getting 89% in MGLContext::deleteQuery...being called 4284 times. Weird.

91

(26 replies, posted in Engine)

I used to play Minecraft on it. True, it wasn't totally smooth, but it was definitely a playable framerate.

Those values are still a very initial set of profile tags. I've been going through MEngine alphabetically and adding a tag to each function. I think I will leave it at MEngine, Common and Player for now, it should give me enough information.

I was wondering if it would if it would count the actual rendering time or not, I assume there's a yield somewhere that will wait for the actual draw? Maybe that would explain the discrepency with timing...

92

(26 replies, posted in Engine)

I'm running out of things I can do on my netbook while commuting, as my netbook currently still renders at 2-4fps. This might be a graphics driver issue, but I had a look at what I can do to fix this and I couldn't find anything.

So I've begun profiling Maratis, to see if I can figure out exactly what it is that is causing it to slow down.

I have uploaded a sample frame to Pastebin. I've not profiled the entire engine yet, as you can see, but it's already shown some interesting things. For one thing, MaratisPlayer::graphicLoop is only taking 72ns (1%) and MaratisPlayer::logicLoop is taking 3us (22%). Also strange is that MLevel::getCurrentScene takes a huge 2us (14%)

The current profiles are done using my fork of Maratis but I've made only minor changes to Maratis, which I don't believe affect performance at all.

The level loaded is just the demo cube, one light, and a camera.

I will add more profiles when I've added more functions to the profiler, and if I've figured out some ways to potentially optimise Maratis. If anyone can see something I've missed, feel free to shout smile

93

(3 replies, posted in Gossip)

I have been trying to plan what I'm doing in my various projects, and I'm slowly coming to an end of the editor GUI and framework system, so I'm looking at what tasks I can work on next. There are a lot of fundemental things missing so far (for exampe, entity selection/manipulation) but in order to keep... motivated, I think I want to try and find a task I can work on which is interesting, even if it's not quite as useful.

One of the options I'm considering is trying to make a video tool. At it's most basic, what I will probably start off doing is making it render to texture, and then encode to ogg with libtheora. In theory I don't think that would be too difficult. What I would like for the video creator to be able to scrub backwards and forwards through the scene, potentially making changes.

Obviously this is far too much work for a small distraction task, however I would like to keep it in mind if/when I do this, so it can be added later. I already have a couple of thoughts for what I can do, the main thing I'm unsure about is how you would go about playing a scene backwards. I know that it definitely can't have non-deterministic behaviours, and have to support anything with negative time deltas... I'm just wondering if there's any thoughts on how to get things to support backwards, forwards and being edited on the fly tongue

So, a little update is due, I think.
I've been incredibly busy since my last update. Unfortunately a large part of that was crunch time at work, so things didn't progress much with my personal projects.
======================================================
She Wore White
To be honest, very little has moved forward with this project, I'm getting some art assets together. As always things are moving at a relatively slow pace, but they are actually moving, so I guess that's good.
======================================================
MIngEd
This has recently made some actual progress that I'm very happy with. To begin with, the GUI solution. I have fallen back to doing this manually. I've created a very basic lua API for rendering and I'm handling the entire editor system, including GUI layout, in lua. Which brings me onto the next thing, I've been extending the lua API for Maratis. I've been wrapping things in modules and classes to make developing in lua a bit easier (hopefully). I've also done the same for everything for editor but placed it in a MIngEd module (so you can do things like window = MIngEd.GUI.Window(Quad(0, 0, 100, 100)) ) I've also added the possibility to npk packages through the Maratis File tools wrappers, and then embedded an npk file into MaratisPlayer, and the minged library. So, now the framework is sort of in place, I've started sorting the actual editor GUI. I've even done some GUI design myself. What I have so far is when you press F1, it shows an empty window. Then you can press (currently F3, randomly) to switch to atlas viewer mode. The window gets replaced by a larger one with the GUI atlas displayed. Especially for you lot, I have a screenshot for you.
http://i.imgur.com/wCrGN.png
Ok, so the atlas system is something I've obviously done, it takes images and stiches them into one large image, and then when I request to draw one of the parts, it calculates the UVs. On top of this, I've also written a font system and can already print strings fairly easily. The main problem I have is that, because I am doing a reasonably large amount of (small) images to put into the atlas for the font, it actually takes about a minute to build the atlas each time I start the program. I'm now working on writing an atlas to disk, and supporting loading a premade atlas, then adding the atlas creation to the build system.
I'm sure I've done quite a few more things, but I think that's enough for now
======================================================
MIngEd-PSP
I've actually got it compiling and linking properly for PSP (with a previous version of MIngEd). I haven't got it running on PSP, because I had to package the assets and everything up, but I think I will abandon this branch, at least for now. It's still something that I would like to do, but it's a job for the future.
======================================================
Tutorial, Particle system & Profiler
Nope. Not done anything. No time. Sorry.
======================================================
For MIngEd and She Wore White updates, I usually complain about things not working on Twitter. Hopefully there will be more interesting updates soon.

95

(2 replies, posted in Scripting)

... That would be why. Thanks...

96

(2 replies, posted in Scripting)

I'm just trying to sort out some lua mouse input handling and I can't seem to get mouse clicks at all. I've tried both onKeyDown("MOUSE_BUTTON_1") and isKeyPressed("MOUSE_BUTTON_1") and both only return false. I can't seem to see any other way to get mouse stuff, but as usual, I'm probably being blind tongue

97

(11 replies, posted in Engine)

I had a quick look at MOText, I just used the atlas system because I knew I could get it working quickly. I think I might get it to fallback on MOText, if I have time, I don't know.

There's a lot of GUI-ish things that still need to be done, like animations... but for now I think, with the exception of keyboard and mouse input, I'm almost done with GUI features.

98

(11 replies, posted in Engine)

I will probably end up using it for that too, yep smile To begin with (because the design is far simpler than complex game GUI) it's for the tools stuff I'm doing, but I am trying to write it in a way that's easy to reuse for ingame stuff.

All of the layout and logic is actually a collection of lua classes, there's very little actually implemented in C++ right now (the atlasing system and RendererDrawQuad is really all it is)

Over lunch, I reused the atlas system to do bitmap font rendering using the same setup. I should be able to do any dialogue box with 2 draw calls with no optimisations, if it ends up being slow (really shouldn't) then I could probably make it ~2 draw calls for the whole GUI.

99

(11 replies, posted in Engine)

It worked great. I had a little problem with my atlas implementation to get it to display properly, but tadaa! Now I can go on and make more GUI stuff smile
http://img41.imageshack.us/img41/6936/boxgx.png

Yes, I know that the top left image is 1px larger than the rest, I will sort that

100

(10 replies, posted in General)

I've had a look at networking libraries recently for another project. I was very disappointed when I couldn't find an open* equivalent for networking. I ended up using this lib which, although old, was easy to get working, and it supposedly would work for Windows too. I seem to remember that, on iOS at least, you can use raw BSD sockets... so most networking libs should be fairly trivial to port.

Even if you don't use a library, it's possible to write quite a simple wrapper over both BSD Sockets and WinSock quite easily. There's a surprisingly small amount of work that you actually have to do. The majority of the work is in synchronising the world, which would have to be hand rolled anyway.