The Eclipse Optimization Project (EclOpti)

[Stein]

* * *

The Eclipse Optimization Project

* * *

**Backstory:**

As many of you might know, Eclipse Event System 3.0(More commonly known as Nightly) has been out for a while, and Snider is having a hard time finding time to fix up and optimize his engine, as well as continue the project altogether. Therefor, after some discussions on the shoutbox on 04/09/2012(DD/MM/YYYY) a band of people decided it may be a better idea to instead of having a single developper, appoint several people with a good knowledge of the language to watch over a repository, in which these selected few can edit and update the code, while everyone is able to track and see what is going on, as well as offer suggestions on how to improve or add code.

Now, while I understand the fears you might have of this turning into another Eclipse Evolution, being handed from person to person making bad additions, I can almost guarantee you this will not be happening here, only a small few people that actually know what they are doing will be granted access, the rest is able to clone the repository but unable to commit their changes, they are welcome to make suggestions and post up their fixes here, we will then review them and post them up in the repository if they are tested and found good enough to be a fix.

**The Idea:**

The idea here, is instead of waiting for Snider to release 3.1, which will likely be riddled with the same issues still and waiting for it to degrade into another EE(because let's face it, the event system is a mess, and there's plenty of other strange issues going on, as well as unoptimized and unfinished code.) that we pick it up with a small group of people, and put our efforts together and our ideas to actually improve the engine, rather than leaving to rot.

Of course, this does not mean you(the community) are excluded from suggesting changes, by all means do suggest us how to change specific portions of the engine to either work more optimized or simply better, bugfixes or even how we should handle unfinished features. We will look over these ideas and plausible fixes, and decide if they're up to the standard we plan to bring the engine to.

**Current Progress:**

Our current progress can be tracked over on the following location:

[[Click Here For The Commit List]](https://github.com/AwakenedSorrow/Eclopti/commits/master)

And here's a list of the things changed so far:

* Bugfixes, bugfixes, BUGFIXES.
* Disabled MipMapping to save some memory.
* Removed a few GoTos from the Event System(a Work in Progress).

**Recommended Build:**

There is no recommended build at this time, we are still in the process of working on it.

Feel free to check out our [GitHub](https://github.com/AwakenedSorrow/Eclopti) and obtain the latest version from there however, we could always use a hand in fixing the engine up!

**The Team:**

We plan to keep this group as small as possible, to prevent everyone from going and coding all over the place, and so we can still coordinate our efforts slightly. If you feel like you're up to the standards, and challenge feel free to apply. And we'll decide accordingly.

* Stein
* Champion Iris
* ???
* ???

Why several people you ask? Well, if one of them doesn't have the time to look into it for a while, or has something else to do (e.g. family issues) there is always someone else that can pick up the work, this way development never fully stops. Not to mention four people see more than one does!

[TorenRenne]

This sounds like an excellent idea. If I had the required skill level to help out I would be in there like a shot, but as I dont I am willing to sit and watch and post any constructive feedback I can.

Thanks for taking the time to have a stab at this.

[Guest]

Considering the amount of problems in EO and how badly optimised it is, it would be easier to actually create a brand new engine. Good luck though, it's quite a task.

[Stein]

> Considering the amount of problems in EO and how badly optimised it is, it would be easier to actually create a brand new engine. Good luck though, it's quite a task.

I have been considering this, but everyone always complained to me they didn't want to lose the event system or other lazy ass features. Quite a pain, because having read through most of the code Snider has written I can safely say that this piece of junk is nowhere near being ready for being used in anything, 2.3 has most of the same issues minus the D3D8 library.

Personally, I would prefer stepping back to MS4 and go from there in patching it up. But alas, the lazy masses never share the opinion of the few that actually know what's going on internally.

[Guest]

Even MS4 has useless code, poorly written code, etc. Starting fresh isn't that hard really. Get the basics of the graphics engine in there, steal the Buffer class and then add all the pretty simple functionality and you've got an already better engine. As for the event system you could rip it or write your own because it's pretty messy.

[Stein]

I'd prefer not to rip it, or use any part of it if I ever were to make my own. It's plain awful, and should never have been set as official until he fixed it up and rewrote half of the darn thing. 

Anyway, starting anew is something I had in the back of my head, the problem is that I was considering what language to do this in. .NET is too abysmally slow to use it for low end 2D games, and frankly I hate OOP. And most other stuff is far too complex to rewrite as a fun project, or for other people to edit easily. VB6 is getting older, and starting over in it is getting a bit odd.. It took me some fidgeting to get it to run on Windows 8.. And for something so simple that really shouldn't happen.

[TorenRenne]

IMHO, startight again from scratch isnt a bad idea, but changing the programming language would kill off most of the people who currently use it due to them only knowing one language. Don't get me wrong, it would be great to write it in another language etc, but would people adopt it?

[Stein]

I'm not saying I'll do it instead of this, might be a sideproject mostly. Let's see how far we can get with this first.

[tslusny]

> I'm not saying I'll do it instead of this, might be a sideproject mostly. Let's see how far we can get with this first.

hey Stein i finished that unloading/loading textures when needed you can rip it from Eclipse Advanced 3.0.9 what i am currently uploading and add it here

[Stein]

I'd rather test it thoroughly and see what adjustments I can make to it as well before blatantly ripping it. (e.g. caching of nearby maps and such)

[tslusny]

> I'd rather test it thoroughly and see what adjustments I can make to it as well before blatantly ripping it. (e.g. caching of nearby maps and such)

i made it load texture and it sets unloadtimer to it with delay of 150000ms

[Stein]

I'll look into it when you get to releasing it then. :]

Anyway, thanks to Richy we now have the constants Enumerated, I pushed the update out just now. Thanks for the help and contribution!

Check the Commit out over [Here](https://github.com/AwakenedSorrow/Eclopti/commit/034dde19700f5298bc053cdf1a9764fc8b42075f).

**EDIT: This change will likely break any tutorial if you try blatantly copy/pasting them. Beware.**

[Exception]

Welp, I'll be able to start my side of work from Friday. Expect MANY optimizations into the way the engine loads textures, and severe reductions in memory usage, so you can have loads of tilesets, characters, etc, and not spend about 5 mins waiting for the engine to load, and it won't go using 500K+ amounts of memory. Assuming Stein doesn't start it first, of course. 

I'm also considering potentially removing FMOD for some other less temperamental audio-library, as honestly, FMOD is getting on my nerves, too. xD

You can also watch our planned todo-list here: [https://github.com/AwakenedSorrow/Eclopti/issues/1](https://github.com/AwakenedSorrow/Eclopti/issues/1) and feel free to suggest anything that we should look into here.

[Stein]

I might look into it today, although since Death has been doing this himself I mist just see how well he's done it and rip his changes if they seem stable enough. Anyway, I've also understood that Snider has been somewhat optimizing the Event System for 3.1, so I'll drop trying to fix it up until he releases it and we can add it into this, don't really feel like fixing things twice. 

I've also added a new issue we should fix.. The screenshot function was never updated to D3D8, now this might not be very important. But meh, it's a bug regardless.

EDIT: Turns out trying to fix up the screenshot function is tricker than I expected. D3D8 is being a pain in the neck again, I've got part of it sorted in [Commit 00b28062c4fd692f4608ffa67e0f73ba0854295b](https://github.com/AwakenedSorrow/Eclopti/commit/00b28062c4fd692f4608ffa67e0f73ba0854295b), but it's not functional just yet. And I still need to remove a bit of nonsense from my fiddling around with it.

[TorenRenne]

So to confirm, your not adding anything/removing anything (just replacing in some cases), so if someone was to start using your Commit listed:

> Check the Commit out over [Here](https://github.com/AwakenedSorrow/Eclopti/commit/034dde19700f5298bc053cdf1a9764fc8b42075f)

Are you changing the way the maps are saved/loaded?

Reason im asking is, if someone wishes to start using one of your Commit's, will they then need to re-do the maps regularly? As those are the largest thing to replace.

If your not changing the way they load/store, I would be happy to try messing around with the thing and see what bugs/errors I can produce?

[Stein]

I'm not really planning on changing the way maps and such are handled at the moment yet. We're mostly working on optimizing systems and fixing current issues, so we really won't be having a lot of changes in data formats as of yet.

Perhaps once everything is sorted we'll start adding new features, but right now there's more important issues to deal with.

[TorenRenne]

Indeed. Ok that's fine, just wanted to clarify that point so I can tinker. Will keep you posted if I run in to anything using the commit you linked to.

[Stein]

Right, took a different approach at getting screenshots to work. It works more like how the DD7 version of Eclipse would do things, so it could probably work better. However, DirectX8 kept complaining about incorrect values even when using the libraries own data types, and four hours of digging through old code and research lead me nowhere, so this is what I turned it into:

```
Private Sub cmdSSMap_Click()

Dim Rec As RECT, hDC As Long, i As Long

' If debug mode, handle error then exit out

If Options.Debug = 1 Then On Error GoTo errorhandler

' *************

' Plain Broken. Direct3D8 is a ducking pain in the ass.

' Please note that this is a WORKAROUND to get it to work right now.

' Will have to look into a proper fix in the future.

' *************

hDC = GetDC(frmMain.picScreen.hwnd)

BitBlt frmMain.picScreen.hDC, 0, 0, ScreenX, ScreenY, hDC, 0, 0, SRCCOPY

Call ReleaseDC(frmMain.picScreen.hwnd, hDC)

i = 0

While FileExist("screenshots\" & str$(i) & ".bmp")

i = i + 1

Wend

SavePicture frmMain.picScreen.Image, App.Path & "\screenshots\" & str$(i) & ".bmp"

' Error handler

Exit Sub

errorhandler:

HandleError "cmdSSMap_Click", "frmMain", Err.Number, Err.Description, Err.Source, Err.HelpContext

Err.Clear

Exit Sub

End Sub
```

Pretty simple really.

[Growlith1223]

for the sound, use Bass.dll, it should be pretty good, right?

[Exception]

Welp, I started my side. If you check the commits, you'll find that the **tileset loading** has been done, amongst two other 'fixes'.

While we are working to optimise the engine, **I do not recommend** that you **currently** just blindly rip from it at the moment! We still need to test each and every thing we add and fix, with different people, just to see how it goes down! The planned texture loading/unloading systems revamp is massively included in that, as we need to make sure that nobody ends up with any texture corruption, or unloading issues.

[dimx]

I think waiting for the files to load in the beggining is better then having them load and reload every time you change maps, there is just more room for mistakes. Also by the looks of it you will be caching adjacent maps so that means you will do this everytime you change maps? Yea it will bring the overall memory consumptiond down but people have hardware now that will be able to run that with no problems now.

If you go your way then I would make each tile as an object and then load only the object that you are using on the map that way people dont throw in tilesheets and probably just use 1/5 of what they acctually have. Alos what someone would do is make a 50mb tileset sheet and only use one tile on the map that means you still need to reload that sheet everytime you change maps.

I like this idea of everyone collaborating together and to help eachother because even the smartest people sometimes overthink something especially if you don't do much planning ahead when proggraming and when you have someone look over your code they will probably see an easyer way of doing something. 

[Exception]

There isn't any room for mistakes…it's not like computers function like human, and suffer to human error. It's programmed to load new tilesets when changing maps, and unload anything not in use. It does nothing more, and nothing less, and the only bad thing I can anticipate happening (albeit, a low chance.) is potential texture corruption, which is why I require testers.

Another thing you should know, on the maps that I've tested, that use 6 tilesets of the 51, it takes an additional **second** to load. Personally, waiting a second to change maps, which would happen due to latency, anyway, is much less hassle than waiting for ages at the start to just get to the menu.

You cannot assume that of every person. EO3 takes about 2 minutes to load for me, and just removing tilesets from the loading procedure alone drags that down to **3 seconds**. Assuming that everybody has infinitely great computers is how abominations like .NET come to exist: the fundamental idea, fine, but it just doesn't work.

And, of course, that would be the case, but I'm going on the basis that the people who choose to use this aren't going to be morons, and will just blindly use this without thinking about what they have to do on their part for efficiency. It isn't a miracle solution, and it does require a teeny bit of thought on the mappers side. If you aren't prepared to do that, then there's no point on you using this in the first place. And, who in the hell would use a 50MB tileset? I don't know about you, but all 51 of my tilesets take 15MB..

[Whackeddie99]

I didn't read any replies, but two words:

ducking Yenius

[dimx]

I was exadurating on the size just to prove my point. I am just trying to help out based on my previuos experience. 15mb of tilesets should not take 2 minutes to load, I have 512mb ram and a 2ghz processor and it would not take me that long. If someone can play BF3 or MW3 why wouldn't they be able to play your game that has 15mb worth of tilesheets people that play PC games have computers made to play pc games.

120 seconds / 50 tilesets = 2.4 seconds per tileset.

2.4seconds * 6 tilesets = 14.4, so it should take about 14 seconds to reload everything when changing maps according to your numbers above.

But also according to you 6 tilesets = 1 second then the client should load 50 tiles in less then 10 seconds, this doesnt add up.

If the persons computer is "slow" why would you want to make it compute different information every time you change maps.

What if someone decides they want to use a little of something from each of the 51 tilesets, this is a hobbie people are not that organized you are loading 51 tilesets again or even the surrounding maps 5 maaps cached or 3 tilesheets used per map that is still 15 tilesheets that are being loaded.

If you are really that worryed about performance switch to c++ or build an engine from ground up it would be easyer. I was just trying to help out by giving my opinion. 8gb of ram you can buy now for $70 a processor 8 core amd $180 not very expensive so don't tell me people cant afford or can't have high performance pcs.

[Whackeddie99]

Switching from Enums to Constants - what is the point of this? Is grouping with enumerations better?