Search options (Page 14 of 18)

2012-01-25 00:22:30

I will have to have a closer look at the memory, I've been a bit busy tonight unfortunately. I do know that often applications preallocate a larger amount of memory than they need. I will do it after I've finished the little changes I've done to the package manager.

But yes, it's Windows 7 x64 on both machines I've tried it on.

I might try to do the profiler at the weekend, I am interested what it might come up with. I will have to see if I can mark memory on the stack as well as the heap. If you would prefer the code not submitted I will keep it locally.

2012-01-24 22:09:50

I had a go with 2 versions of Maratis, the first being built with Visual Studio from svn, the second being the precompiled download, both have similar results. The download went up to 89MB with YoFrankie, the svn version stopped at 74MB strangely.

2012-01-24 19:21:47

I'll send myself the mech mesh and do some tests at home. I wasn't using any profiler to get the numbers, I just glanced at windows task manager.

It's unfortunate that I can't seem to load the mech into unity, no matter how hard I try

2012-01-24 18:32:56

I will try and do some benchmark tests with the mech mesh and svn revisions, unless you have an archive of previous builds I can use.

If there's anything more detailed you want, I can quickly plug in either memory or CPU profilers I recommended within a matter of hours to get a quick reading on what sort of things are heaviest. I was just suggesting wrapping it up nicely so it could be used by others in future.

2012-01-24 16:21:27

I have checked that there is nothing apart from the box.mesh in the meshs/ directory. I have no idea what's happening :S

There are some tools on various platforms that will allow you to do CPU/memory profiling, but very few are cross platform and will allow for Maratis users to optimise their games properly. Not sure if that's important to you. What I was thinking is that we can add a MProfilerContext to MEngine, and then create macros to do something like the following:

#define M_FUNCTION_PROFILE() \
MProfileStack func(__FILE__, __FUNCTION__);

Which will wrap up checking if there's a profile plugin attached and will release at the end of the scope. I actually had a look at profilers before and Shiny Profiler looks nice and simple to make into a plugin

With regards to memory management, it would probably be a bit more hassle as it means overriding new/delete globally so you can keep track of the memory yourself. Not as painful as my fopen hack as C/C++ will allow overriding them but that can tie into the MProfileStack again, then you can print out the memory as it's been saved, with the file and function it was allocated in. Of course you don't want to have either of these things running in a production build, but if they're wrapped in a plugin, will allow projects to test what's happening, and the MProfileStack class should take minimal overhead if there's no profiler. Can even create a FinalRelease player build which defines M_FUNCTION_PROFILE in the build process, so it's not even implemented.

EDIT: I had a quick look at memory profiling, and found this which basically explains what I mean, but if we have the MProfileStack, we can actually point out when and where the allocation came from

2012-01-24 15:47:09

I was using the latest svn version without any modifications, built with scons.

if you put sleep(10); at the end of the loop, the thread will sleep for 10ms. It won't have any effect at all (until you're really pushing the CPU) apart from just letting the OS know that you're not actually using so much power. Still wouldn't explain why the model suddenly made the CPU shoot up so much, but then again, I guess ~500k tris probably has something to do with that.

With regards to the memory usage, like I said, I'm not getting much done with the PSP stuff right now, so I may as well put that on hold for now. I've done some memory management at work, so if you want, I can try to take a quick look at that. Might be interesting to make a profiler plugin for Maratis actually

2012-01-24 15:13:11

It wasn't an entirely empty scene, it was the box.mesh stretched into a floor with SponzaFPS mouse control script and 2 lights.

If there's any more testing you would like me to do, I can try and throw similar things at Unity. I'm also still chasing up some things about the PSP work, so if I can't get that to finish up, I might try and do a bit of code profiling, see if I can work out where the memory is hiding and what's taking so many CPU cycles.

I seem to remember that, if you let a process just run on, it will eat up as much CPU power as it can (in this case 49% makes sense as it's almost all of one core...) what you usually have to do is stick a sleep() at the end of the loop. I haven't checked if Maratis does this yet, but it's potentially what might cause the phantom CPU usage.

2012-01-24 14:01:50

So, I've started having a play around with Unity. Apart from the fact that it has more features than Maratis, I don't think that it's that much better. I haven't got any numbers yet to back up the performance, but the development experience seems to be pretty awkward. I asked one of my colleagues to help me with the interface because very little made sense to me at first glance. I guess with a couple of tutorials I would get into the Unity mindset and things would make sense. Maratis, on the other hand, I didn't need a tutorial, was nice and simple

Ok, so I did build a standalone .exe for Unity but I haven't been able to get the mech model from Umar yet, so I removed the model from my Maratis test too.
Unity runs at ~5% CPU with ~17MB memory.
Maratis runs at ~49% CPU with ~71MB memory.

When I added the model to Maratis, the CPU usage went up to 95% and the memory to 103MB. As soon as I can get the model into unity, I will be able to see whether the model has significantly more overhead than in Unity, but as it stands, it's clear that something's working harder than it needs to. All I have is 1 light, a box (/plane) with box collision and the standard Sponza controller.

Still, I don't think it's that bad a result for Maratis. Unity has millions of dollars poured into it's development and has been optimised a lot *shrug*

EDIT: This PC Is an AMD Phenom II X2 550 @ 3.1GHz with only 2 cores unlocked

EDIT EDIT: Unity doesn't seem to want to load the mech model, whatever format we give it, obj, fbx, whatever... Oh well, I'd best get back to work

2012-01-24 10:42:02

I just need to have a little rant here, feel free to ignore me.

Every project should use source control. I have read that every project with more than one contributor should have source control. I disagree. EVERY project should have source control. It is the most useful tool during software development. If something breaks, you can roll back and find out where it broke. If you forget what you've been working on, you just diff against a previous revision and you can clearly see all the changes you made. Without source control, it's impossible to keep on top of anything more than the most trivial project.

So, a project/company uses source control. It's all fine? No?

No.

Not when you have a system that allows only large commits.

For example (and any similarity to real life is entirely coincidental... honest) Imagine the following situation. A major part of a game GUI. It was written for one resolution with some hardcoded magic numbers that noone remembers how they appeared. Then someone is told that it has to support 2 more resolutions. A little investigation into the magic numbers followed by giving up, pressing print screen and measuring the pixels in photoshop/gimp/paint/... to calculate the magic numbers for those screen resolutions.

Then imagine that, for whatever reason, the game has to support a minimum of 6 more resolutions, with the potential of many many more. So the GUI needs to be scalable, right? Enter stage someone who looks almost exactly like me, but couldn't possibly be me because this is an entirely contrived example. This person gets his head stuck into the project for a week, fixing bits here and there, generally doing a tidy up and making everything scale nicely until he gets left with just the accursed magic numbers. Up until this point most of the fixes have been small and easy to keep on top of. Fast forward 3 days. The magic numbers are eradicated. The programmer feels good about himself and sets about rebuilding the bits of the GUI that had been stripped out in the process. He gets about half done. Then he gets pulled away for a 2.5 hour long meeting. When he gets back, he looks at what he's done and for some reason the bit he's been working on is, for some unknown reason, 2x too large. Now, of course, making the numbers half as big could solve the problem, but it doesn't explain why they're suddenly so big. And diffing against a previous revision wouldn't work because it's 3 days old and relies on magic numbers.

In this entirely fictional example, the solution could have been to fix a little and submit it to the central repository. That doesn't always make sense because if it's a fairly major change, you can't submit small parts without compromising the stability of the central repository. What would be sensible in this case is to use a distributed source control system, such as git or mercurial. This would allow a local repository which you can commit to, diff against, branch, whatever you want. Then when the whole task is completed, it can be pushed to a central server.

</rant>

2012-01-23 14:12:29

Unfortunately I was unable to do much testing during my lunch break as I had to sort out the billing on my website. I did, however, have a quick look through the npk code. Much as I'm still not 100% sure what it's doing, I've changed my mind and I think that the package isn't actually loaded. npk_read seems to open and read chunks of the package every time. So that would mean that leaving packages "mounted" should be acceptable. Will try and test further when I have time.

2012-01-23 12:53:43

Great Good to hear. I hope Anael won't mind me covering what he's already got, but I think it will help me to get these things started. If there are things that you would like to see then please please please let me know. So far, I think I will try and do the first of these tonight, and see how it goes:

- Setting up a basic game plugin project with premake4 using Anael's example as a base
- Creating a game state machine
- Design patterns - command for controls?
- Save Data (Hmmm, this might be a good use for protobuf )
... [watch this space]
- Changing the premake project to build a custom player for debugging purposes

I don't intend to just dump a whole load of code and say "well, this works, just use it" as I know that can be a bit frustrating, so I will try to type out as much as I can, explaining as I go (Hopefully I can type fast enough for it not to be too boring and keep things moving)

As I said, I will be doing this alongside making my game, so I should be able to cover most aspects of game programming, if you just let me know what you want As soon as I've made the first video, I will upload to youtube and link here

EDIT: I have tried a couple of times to make the video but kept messing up I then gave up and made a late dinner, I'll try again tomorrow. I think I've ironed out the issues I was having

2012-01-23 12:31:53

To be fair, I have little experience with this, I just assumed that searching through a large package would have significant overhead. But you're right, I think it calls for some testing. Have you thought of adding profiling code to Maratis?

2012-01-23 12:22:30

I think, what I would like to do is have the ability to load a package from within the executable. It would make a cleaner demo for me, and I'm pretty sure that I can fit within the 64MB limit. I don't own a PSP-1000 and I'm sure if I were to send the demo to Sony, they can find something that would run it But I will also add support for loading packages from the filesystem, which will allow larger homebrew games to be made. For it to work efficiently, I think it will need to be able to split the packages up as, regardless of RAM usage, having a giant package being searched by a ~7 year old device seems like something that we might want to avoid.

2012-01-23 12:07:44

package discussion continued here

2012-01-23 12:06:28

As requested, continued from PSP Thread

As I said, I find it quite difficult to follow a lot of the NPK code, but I believe once the package is opened, at least some of it is stored in RAM. I can't be totally sure yet, I would have to delve in a bit more. It's quite possible that it's doing some magic and only loading the bits you request.

On a side point, when scanning through the headers to try and find the relevant structs, it turns out that there's a NPK read callback, can possibly tie that into an animated loading screen system... hmmmmmm

2012-01-23 11:35:41

For me, I don't think these limitations will be too much of a problem as my demo will only be one room. I should be able to fit it into the memory of even the PSP-1000. For future potential Maratis-PSP-homebrew games, I will make sure that you can load and unload packages from the filesystem properly, and not keep the package open indefinitely (as it currently does).

That also, however, means, supporting multiple packages, so games can be built into smaller chunks. Whereas the package manager technically will support multiple packages without any problem, the Maratis folder structure doesn't lend itself easily to it. At least for publishing. Rather than packaging the whole project data, as is currently done, having the following structure might help:

project
|---frontend
|   |---meshs
|   |---maps
|   |---sounds
|   `---level
|---game
|   |---meshs
|   |---maps
|   |---scripts
|   |---shaders
|   `---level
|---level1
|   |---meshs
|   |---maps
|   |---scripts
|   |---shaders
|   `---level
`---level2
    |---meshs
    |---maps
    |---scripts
    |---shaders
    `---level

Although, I think that might cause more problems...

2012-01-23 11:02:22

I had a look at the NDS stuff, and it appears to be because devkitARM loads the entire program into memory, the 4MB limitation being the RAM size of the DS. The PSP-1000 has 32MB whereas every version after that has 64MB. Even if devkitPSP does the same thing and loads the whole program into memory, it's got a bit more wiggle room.

I guess having the NPK separately might be easiest, I'll have to see where it would expect to be loaded from

2012-01-23 10:20:25

I think you can load files from the memory stick using devkitPSP, so potentially I could just stick the npk file on there, but I will have a look if I can somehow give libnpk a buffer. Shouldn't be _too_ bad. I have had some caffeine and can maybe work my way through the code at lunch

2012-01-23 09:55:24

I have no idea about the performance either, but if I can get something playable running with devkitPSP then I might be able to get one If you say people would be interested, then I shall do my best to make it clean and nice for other people to use

I realise that the iOS project didn't use scons, which was why I suggested using something else. With iOS it's (fairly) easy because there's just the one environment to set up (xcode).

I'd heard about premake several times in the past and I've been playing with different meta-project types, but not got around to premake until recently (I even started writing my own python one ) It seems to be very nice and fairly easy to extend, if you fancy writing into the jungle of embedded lua. As I've not got a great experience with lua, doing more than the inbuilt functions seems a bit daunting, and they currently don't support changing the compiler from the default one (gnu make - gcc, vs20XX - cl etc) and also don't support visual studio NMake projects. I could have a look at forking and extending premake4, but it might take a while. Also, I did find a fork (which _may_ have been merged back) which supports gnu make and devkitPPC for building Wii projects, so I guess that's an option.

Also, it occured to me that for PSP, I would have to build the npk file into the executable, which means I need to persuade libnpk to take a buffer. I had a look at the code for libnpk last night and... well, I should look when I'm not sleep deprived... that many gotos hurts my little brain

2012-01-23 09:43:18

Hey Vegas, the site looks great now Keep up the good work

2012-01-22 22:47:19

My game development still isn't in full swing yet, I'm waiting on a couple of pieces of artwork and a meeting to decide what the actual scope for the demo is. That basically leaves me with a bit of time to twiddle my thumbs before I can get rolling properly and now the package/publishing is wrapping up I'm poking at other things to keep my fingers busy.

One thing I would like to do with my demo is to send it to Sony in the hope of charming a (Vita?) devkit from them. For this I want to have something on a Sony device, so I've been playing around with the homebrew PSP devkit, part of devkitPro. Having a look at Maratis, there's not an awful lot that would need to be done apart from rewriting the renderer.

Firstly, a couple of questions. Does anyone else have any use for the homebrew PSP version or should I just make it for myself? If other people are interested, do they have any preference as to how the project is built? It will be based on the current iOS build, but obviously there's not really a project file that would work, as it could be built on Windows, Linux and OSX. Also, I'm not sure the existing scons build system would really work, I'd have to look into it in more detail. I was considering premake4, as I'm planning on using it for my project, but it doesn't yet support changing the compiler. The other option is CMake I guess. Anyway, thoughts?

2012-01-22 21:43:09

Hey, great! Thanks for sorting through my submission I will take a look at writing the mesh files directly to the package tomorrow Maybe expose the teakey and check that the game plugin can change it for publishing and loading. The only issue is that the plugin doesn't necessarily know that the package manager _will_ be the NPK one, so there would be no guarantee that the encryption needs 4 ints...

I noticed that, for the OS X publishing, you commented that all the data could be moved into the .app. I could probably do that pretty quickly too, although I would have no way to test it.

2012-01-22 15:15:08

Continuing from another thread. I have a few ideas for the plugins.

NOTE: this is a brain dump. Expect no coherency

Firstly, I guess it's unfair to not have plugin functionality for iOS so it would have to be extended to support static linking. My initial thought is to have a macro for initialising plugins, when compiled with something like M_PLUGIN_STATIC it would add a start(plugin)Plugin prototype otherwise it creates a startPlugin prototype. Likewise, there can be an implementation macro that wraps up both situations. I can't remember what happens with static constructors in staticly linked libraries, so I will have to take a look into that, but potentially that could provide the plugin initialisation.

Secondly, as Anael mentioned, separate plugins for engine/editor might be confusing for users, my suggestion is to, during publish, check whether the plugin is needed by MEngine, and not publish those that aren't. That way users can just unzip plugin packages into plugins/ and not worry about it.

Also, maybe get Maratis/MatatisPlayer to look in another directory for standard plugins as well as the project plugin directory. On Linux, maybe ~/.Maratis/plugins, %APPDATA%/.Maratis/plugins for Windows. This would give a nice central local repository. Maybe have a list of used plugins stored inside the .mproj (although when published, just load all the copied ones)

Finally, and most crazily, maybe having a repository for plugins which Maratis can check and download. There would be no need for the repository itself to be centralised, just a plugin list, probably in xml, with urls and checksums.

Anyway, that's a quick high level brain dump. It would require moving the plugin management into MEngine. Hmmm, I can think of a couple of reasons why my project might benefit from that. Maybe my next task?

Also, if we could scan the computer for gcc-arm (windows at least should have an environment variable if using devkitARM) then could potentially even link an iOS application from the editor... as everything should be interacting with Maratis, there would be little need for the iOS SDK... sorry off topic

2012-01-22 14:44:54

I have no problem with the code being GPL. If I mistakingly made it zlib, it's because it originally was written in MEngine.

2012-01-22 12:29:31

Thanks, I guess I should have done some of that cleanup myself... I'm sorry.

I guess it would make it more difficult if you had 2 plugin directories? Something like ~/.Maratis/plugins for editor-only plugins and $PROJECT_DIR/plugins for game plugins which could potentially also have editor effects? Or game ones which have a dependancy, so StartPlugin returns bool, and it can query a list of editor/game dependencies, checking whether they're available and/or loaded (first? Would have to make sure there are no circular dependencies) But yes, I guess this conversation should be moved to the plugin thread. Not overly important now. It was just something that came to mind with the publishing.

Search options (Page 14 of 18)

Posts found [ 326 to 350 of 440 ]

326 Reply by Nistur 2012-01-25 00:22:30

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

327 Reply by Nistur 2012-01-24 22:09:50

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

328 Reply by Nistur 2012-01-24 19:21:47

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

329 Reply by Nistur 2012-01-24 18:32:56

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

330 Reply by Nistur 2012-01-24 16:21:27

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

331 Reply by Nistur 2012-01-24 15:47:09

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

332 Reply by Nistur 2012-01-24 15:13:11

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

333 Reply by Nistur 2012-01-24 14:01:50

Re: Question: How many Tri's (roughly) can maratis handle? (26 replies, posted in Engine)

334 Topic by Nistur 2012-01-24 10:42:02

Topic: A little rant about source control (0 replies, posted in Gossip)

335 Reply by Nistur 2012-01-23 14:12:29

Re: package file request (150 replies, posted in Engine)

336 Reply by Nistur 2012-01-23 12:53:43

Re: Potential tutorial series (47 replies, posted in Tutorials/Examples)

337 Reply by Nistur 2012-01-23 12:31:53

Re: Maratis on PSP? (14 replies, posted in General)

338 Reply by Nistur 2012-01-23 12:22:30

Re: Maratis on PSP? (14 replies, posted in General)

339 Reply by Nistur 2012-01-23 12:07:44

Re: Maratis on PSP? (14 replies, posted in General)

340 Reply by Nistur 2012-01-23 12:06:28

Re: package file request (150 replies, posted in Engine)

341 Reply by Nistur 2012-01-23 11:35:41

Re: Maratis on PSP? (14 replies, posted in General)

342 Reply by Nistur 2012-01-23 11:02:22

Re: Maratis on PSP? (14 replies, posted in General)

343 Reply by Nistur 2012-01-23 10:20:25

Re: Maratis on PSP? (14 replies, posted in General)

344 Reply by Nistur 2012-01-23 09:55:24

Re: Maratis on PSP? (14 replies, posted in General)

345 Reply by Nistur 2012-01-23 09:43:18

Re: Maratis help site (9 replies, posted in Gossip)

346 Topic by Nistur 2012-01-22 22:47:19

Topic: Maratis on PSP? (14 replies, posted in General)

347 Reply by Nistur 2012-01-22 21:43:09

Re: package file request (150 replies, posted in Engine)

348 Reply by Nistur 2012-01-22 15:15:08

Re: Plugin system concept (37 replies, posted in Engine)

349 Reply by Nistur 2012-01-22 14:44:54

Re: package file request (150 replies, posted in Engine)

350 Reply by Nistur 2012-01-22 12:29:31

Re: package file request (150 replies, posted in Engine)

Posts found [ 326 to 350 of 440 ]