Both words are at the forefront of my thoughts this day. I drop in lots of segments, it gobbles up all the memory, then crashes. Wonderful. My task today has been to first track exactly how much memory is being used on segments (and by extension entities) and then relay that to an on-screen resource bar so I can see the resources grow the larger the level gets.
First Person Game Creator
I did an educational version of FPSC called FPGC which used some extra features such as an entity resource bar so I already have code for this, I have added segments to it now so it's comprehensive.
Notice the green bar at the bottom of the screen. It is nice and out of the way, and will grow as you add things to your level. It will turn red when you are over 900MB of memory used. I plan to cap all levels at 1GB of content, to then allow 800MB for the real time light mapping process and other operations of the application. This should keep me within the virtual address cap and prevent catastrophic crashes. The above bar tracks both segment and entity usage so it's pretty good measure of what your level consists of.
Next Step
Now this is coded, my next step is to add some code to stop allowing the user to add more entities and segments if the maximum resource is reached. I think this is better than a random crash and allows the user to backtrack and remove some items to finish their level. I would have liked to provide an infinite amount of space for your creations, but for this product we'll have to live with placing content across multiple levels. There is a technique of loading in content as you get near it, but that's a whole new engine and another product! Maybe next year :)
Signing Off
The day started late so I will be coming back after dinner to do a little more on this and try to get it to the point where the software cannot be crashed, no matter what I add and what I do. No sense moving on before this is cracked 100% which is the sign of a professional coder (that is, not get excited about a new feature go off to code it, but to stay with what you've done and make sure it's bullet proof). I'm not saying that's me, but I try!
I like those features like that progress bar and entitie limitation to prevent crashing i think is very good to compress the level as much as the user can but still it can be a very good level!
ReplyDeleteWill this mean were limited to small levels again?
ReplyDeleteBummer that you didn't win TUC2... I thought your app was a shoe-in based on the positive feedback it had received. Although, you were named the best for videos and blog :) Bring on TUC3?
ReplyDelete"I would have liked to provide an infinite amount of space for your creations, but for this product we'll have to live with placing content across multiple levels. There is a technique of loading in content as you get near it, but that's a whole new engine and another product! Maybe next year :)"
ReplyDeleteClearly infinite is a somewhat unrealistic objective and not required but the statement seems to suggest and confirm that at least FPSCR will a replica of FPSC classic in this way though the world size is due to be increased. I guess that means less objects and less detail per object per level and not equal or more to FPSC classic?
Larger world size and same mem cap (object Limits) does not seem to make sense unless ones game requires sparesly detailed levels, accepting that some detail can be achieved with textures and so on by clever use of them and design of course to give the appearance of greater detail.
Is it likely that the next thing is the world size will remain as FPSC classic too? How else will you accommodate mem and or object limitations.
Overall its a serious blow to Reloaded it would seem and already a suggestion that it wont be what users need and another possible engine to follow - perhaps sometime down the road.
Unless I am reading this wrong and way off track it just is not going to make it for users and may be better to stop now and start the new engine from scratch.
I understand of course that that would put TGC perhaps in between a rock and a hard place having a commitment to output Reloaded by October or thereabouts, however it looks as if it is starting to look like a non starter for for a serious contender for a much improved engine meeting users needs.
Perhaps I am jumping the gun but from your statement it looks bad and no future for something which is not yet even a reality.
A sad day and bad news I suspect for many who had hoped for what looks like what is not to be. I cant see Reloaded getting further support if its clear that it will be a short term improvement for some issues but not other vitally important ones and is to be an engine already scheduled to gather dust and be relogated to another FPSC history lesson before its even seen life as it were.
Ah well more waiting for another product and more years to follow for everyone. It was what many had suggested in the first place and I guess everyone knows is what was always needed. Hopefully any new (new) engine in years to come if it ever happens will be users saviour.
Its such a sad day really to me I am lost for words for a moment something I am not well known for - cant really believe I read what I did to be honest, bit of a shock to the system :-)
Picking myself up off the floor I am still alive but struggling for a moment. I will soon recover and wonder around in a daze wondering what that was all about? (FPSCR) here today gone tomorrow :-) Disaster.
Wow wow, you jumped the gun there buddy. Haven't you read his previous blog where he clearly states his intention to drastically squish memory usage per segment. Unless I got it all wrong well be able to have higher detail in the same or even greater size levels due to decreased overhead of each object in the game. Fingers crossed.
ReplyDeleteAs you know, I don't give up at the first little obstacle ;) My blog is pretty much a transcript of everything that happens, so you're going to get a LOT more shock moments like this one before we're done.
ReplyDeleteMy plan remains to increase the map size to 200x200x20 (25 times larger levels) and a low memory LOD terrain system to cover the whole area. The new levels will take you quite a while to walk from one end to the other.
Given what the engine is showing me right now, I will be looking at reducing the per-object memory footprint with a few techniques I have rattling around in my head. One of them is to create a new kind of instanced object which shares the geometry of a parent object and then apply the lightmapping (and modified mesh data) at the point where the DirectX VBO object is updated. This means we only use memory where it is actually required and no duplication occurs. Quite a bit of work, but it means I can get the per tile segment memory footprint from 2.5Mb to a few kilobytes. It's all theoretical at the moment so continue reading the blog (if you dare) to see what happens. I agree it makes no sense to take a step backwards, Reloaded needs to surpass the limits of the previous product.
P.S. Thanks for the TUC2 comment, it was a fun challenge and a great opportunity to play with new technology :) Maybe some of it will find it's way into Reloaded at some point, perceptual computing is very cool!
This might seem like a silly question, but why is there a 1.8 GB limit?
ReplyDeleteI operate my current FPSC installation with the memory cap turned off as I have more than enough memory for FPSC to take up 1.8 GB with room to spare.
Is there some hardware reason it has to be capped at that, or is it just to stop crashes on systems with 2 GB of RAM? If it's not, couldn't FPSC examine the hardware and allocate a reasonable amount of memory (for example setting a cap at 4.5GB in a system with 6GB)?
Like I said I don't know if it could be done, but at least it wouldn't look as though FPSC was catering to the lowest common denominator (which there's nothing wrong with in of itself, but I would have thought people with better systems should be allowed to push them).
1.8GB is about the safest maximum for a 32-bit application which is what FPSC-R is based on (DBPro is 32-bit) as it relates to the maximum size address you can specify with 32-bits of data (DWORD). To get things like 4.5GB I would need to write quite a bit of 64-bit code, and I have not dared think about such a thing in case the project was so huge it wiped my brain. Lots of 64-bit systems these days now, so I dare say at some point the leap will be made, much like we did decades ago when we went from 16-bit to 32-bit :)
ReplyDeletetbh when looking at that screenshot and thinking about what a 1.8mb cap means again - it just is a dissapointment.
ReplyDelete(That is mainly because when the screen shows just 20 lowpoly models and the greenbar seems well already too big just for those small things :/ )
FPSCR seriously can not go the same path as its Older brother.
No matter how much u save memory with your improved entities and so on code
judging by the screenshot it still leaves the player with less room to create something better.
Maybe it is time to rethink this? That is why you are doing those blogs to keep ppl informed and to get feedback and this one oooh this one makes waves, in the wrong direction.
moving to 64bit? worth thinking about it....
Well for me going to 64bit is not the solution.
ReplyDeleteYou can't limit a game engine and even the games created with it to 64bit systems.
Also no current game wants to only have 64bit systems, they are all able to run under 32bit systems.
What we really need is a way to get a nice and fast memory managment which handles this problem. Even if this means more work, in the end it will be better than just stepping to 64bit.
Take other engines for example, they all run with 32bit systems and are able to show a lot more details inside a level. This is because of "perfect" use of culling, LoD and object loading routines.
This is what FPSC needs.
I just hope that Lee is thinking about that and maybe try to invest more time into it, as this is what needed.
Than if this works, get back to shader, physics etc.
But I agree with most people here, releasing an FPSC-R with the problem that really fast get to the memory limit will not be that good. A lot of the people are upset about it (even in our german forums) and FPSC-R needs to fix it.
An idea which comes to my mind right now:
ReplyDeleteWhy not give up the idea of a big universe.dbo and just load all objects seperate and instance them? So there is no problem with the building process, just load what is needed and than unload it from memory. The same thing can be done ingame.
Create automatic routines to load and unload needed or unneeded objects. This could maybe even combined with the object culling system in some way. So if the object is hidden away etc we may be able to unload it.
Just an idea so...
Fear not, I am not leaving this issue hanging. My plan is to allow bigger levels with no build wait. Right now I have eliminated the build step but not made the level bigger, that's what I am working on now...continue reading, do not despair ;)
ReplyDeleteIn a few words have faith!:)
ReplyDeletestuff like ..... There is a technique of loading in content as you get near it, but that's a whole new engine and another product! Maybe next year :).... makes us upset
ReplyDeletethere shouldnt be already a plan for a fpscr2
not even for another engine, this one hasnt even reached a alpha stage
You see the power of words is pretty big - especially when there is a community that follows this blog.
Now it might just be wiser to talk about FPSCR only in this blog
as things like this sentence are just distracting and confusing for people (at least for me they are)
i hope you understand how i mean this and it is in no way ment that u need some kind of writing director/ it just might be better to not go offtopic as this blog is about FPSCR.
Lee so far your writing was actually pretty entertaining! in a good way
The loud response of "NOOOOOOOOOO!!" with regards to the small memory limit has caused Lee to think carefully about that limit. Have faith, people. Lee knows what he is doing and he will make absolutely sure that FPSC-R is better in every way than its long-lived predecessor. (crrrrap that sounds preachy!)
ReplyDeleteSwitching to pure 64bit is not the answer. Every single application can switch automatically or has a 32bit version and as such there is little or no incentive for most people to buy a 64bit computer. Lots of people still have 32bit computers and you can even still BUY 32bit PCs.
With careful management of textures (UDK-style streaming textures would be amazing) and prevention of duplicated meshes, FPSC-R will be free to have enormous levels with high levels of detail.