SyntaxBomb - Indie Coders

Just a Snapshot

The orange line you see in the picture is a physical collision that can be modified according to the shape you desire

Oo, that looks very swishy, great work. You should make a YouTube video of it in action

Great stuff!   

Thanks guys

Its too early to make a video..
There is still a pretty much work to do

I did so much and still so much to be done..

But I see some rays of hopes.

Quote from: Hardcoal on December 30, 2019, 03:24:47
Thanks guys

Its too early to make a video..

Sometimes it feels like you're coding forever and not making much progress and then other times it all just comes together. Keep plodding on as it looks like you've done heaps of work so far

I want to say that along with trying to develop my current Editor..
Im also experimenting with a side editor. with another concept..
Just trying to see a different approach to the one I have taken.

The approach Ive taken with my current Editor, I would not take this day.. Relying on Blueprint..
It is very time consuming.. (But will see..)

Besides.. it so fun making a new start. when everything flows so fast.. You Code fast..
Since its just a prototype

You should always work parallel Just in order to make sure youre on the right Track

Very impressive looking UI, intriguing work - Happy New Year!

very clean and nice looking UI..nice work..

Thanks Alien.. I will keep improving it

Things are going rather well with the Editor. although Ive taken a Break.. for some reasons..
The thing is.. Even though it goes well, I find little energy to continue ATM..

Im also Experimenting on another Editor I started, So it takes some of my Energies..

I just managed to make that when I load my Editor it will only load one map. and each time i press another map that is not loaded it will load it only than.
This saves the loading time of the whole game in one go.

Now I need to work on Fast PlayMap to ReplayMap System.. Shouldn't be too hard..

Speed Is essential For a comfortable Game Editing.. You cant make Discounts about it.

Sometimes when I do stuff. Im kinda amazed it actually works..
I cant believe something so complex as this game editor.. can Handle the whole complexity of itself.

Well. Up till now, when I Did Play Map, And Stop Map, There was a slow process of loading the map again.
I found out a way.. to turn 10 seconds of loading to 0.1 second of loading.

Even in unity they dont have that, and Thats funny. such a big company cant think of a way to make Reload map faster..

The best solution for this in my opinion (which i didn't fully applied yet) is To clone each action you do to an identical map that is in the memory.
Then After stop, you just switch the played map with the cloned map.
This way you get instant Play and Stop..

I think In unreal that might be what they done.. because there is no loading time their. But im only assuming.

Im doing many things to make processes faster..
For example, when I load a game to the editor. I only load one map to memory..
The Rest of the maps are only loaded when you try to switch to them.
Saving Editor Loading Time.

That cloning approach has drawbacks:

- events need to be re-registered (as new object instances replace existing ones)
- old objects need to get properly cleaned up (unregister from events, unregister from globals, ...)
- you will clean a lot of stuff from memory after doing so (mem cleanup)
- while cloning you duplicate required memory (not a biggy for small projects - but think bigger, more ressources, ...)

I do such a think in my game for "savegames" - and it is prone to lead to segfaults/errors/... once you need to tackle memory leaks
Memory leaks? Yes ... if you forget to unregister an object properly, then it might be hold by some entity - and that other object holds another object (which should be removed too) - at the end you might have a chain of objects leading to "old map" not being removed at all and staying in memory.
To check this out: keep up the process explorer / task manager / "top" (on linux) and maybe even print out the amount of GCMemAllocated(). Brucey also added some stuff to BCC/BMK/BRL so you could build your individual BMK/BCC which counts alive objects. That way I managed to track down a lot of mem leaks happening because of forgotten properly done cleanups of certain objects.

Once you added display of GCMemAlloced() you should reload your map ... reload your map ... reload your map (and start "play" each time). If memory increases there, then more and more "managed" (so "cleanable") objects are alive. If that value stays pretty much the same - but Task Manager / top /... show an memory increase, then you are possibly leaking memory.


I was not aware of this earlier - as on Linux the memory increase was lower than on Windows - but I leaked 11 MB per Savegame load. 11 MB of "objects", not graphics... that was pretty much. On Windows with "legacy BlitzMax" and Threads it got even worse - a user reported the memory usage climbing from 200MB to over 2GB after some savegame deserialisation. But even after fixing stuff for NG it still happened in legacy - and only with "threads". So the legacy GC has some trouble with whatever I am doing (NG's GC can even tackle circular references - which I should not have that much as I avoid them like hell).



Hope it does not concern you - but better check that out (memory leaking) and also make sure that the core function of your editor works: running the compiler etc.


bye
Ron

I was testing memory increase.. all clean..
I had no errors what so ever..
if you program your stuff correctly it will work correctly..

Im not their yet but I think I got it under control.

> if you program your stuff correctly it will work correctly..

In my case it was hand made positional 3d audio which hold reference to an entity which else would clean up. That entity was kept - and with it some references it hold - which referenced other stuff ...
So at the end some audio stuff was keeping my game code from cleaning up properly.

Just want to say that as if the audio module was a "third party" thing you might have considered stuff in there to be "working no matter what I do".


Also "decoupling" (eg. through "event systems") can create issues (assume you send out an event with an object as parameter - and the parameter is stored by some listener as ":object", it is hard to find the reference then when cleaning up). Pay attention when coding such stuff.
Maybe a reason why some prefer "IDs" over "references" (albeit this might lead to other issues then ...).


bye
Ron