search

thelinuxlich / artemis_CSharp

Artemis Entity System Framework ported to C#
Other
341 stars 78 forks source link

Refresh of NuGet packet? #96

Open GrafSeismo opened 8 years ago

GrafSeismo commented 8 years ago

Will you offer a new NuGet packet? In current 1.3.1 i am not able to add a component without error of null object.

mohammedh123 commented 8 years ago

+1

nuget version is missing many fixes

Maximusya commented 8 years ago

We use Artemis projects (i.e. source code) because we tinker with it a lot. The code base is very small and is built without any dancing or hacks.

I don't justify the staleness of the nuget package - I just wanted to point out that it's probably not of real value at all)

GrafSeismo commented 8 years ago

sad to see how dead this project is now :(

thelinuxlich commented 8 years ago

I wouldn't say it is dead, it has some quirks but it is somewhat complete. There isn't enough research about Entity Systems to advance this.

KellanHiggins commented 8 years ago

I agree with @thelinuxlich and @Maximusya. This project isn't dead, it is stable. I've had very few problems with the framework after using it almost every day for 2 years.

The only thing I could see would be to look into improving the performance, but I am no C# performance expert.

Adam Martin is writing some new articles on Entity Systems in the coming months. Here is a link to his Patreon page (https://www.patreon.com/tmachine?ty=h).

thelinuxlich commented 8 years ago

Maybe we could create a new version adopting everything from latest C# just for syntactic bliss? :)

KellanHiggins commented 8 years ago

What do you mean? Update it to C# 4.5 or 5? I think it would be good to keep it compatible with Unity and C# 3.5.

thelinuxlich commented 8 years ago

Okie dokie

KellanHiggins commented 8 years ago

I am still up to change it of course if people think there is some advantage! I am not using it with Unity anyways, so I don't know if what I suggest would be bad.

GrafSeismo commented 8 years ago

Please do not take following as rule, but i had some ideas we might think of: What is about .NET Core support (UAP)? What about dropping XNA structure and support, at least dropping MonoGame due to this project seems to be a never ending bugfix and may will not support .NET Core in the near future? What about replacing Bag, Tag management & System management with SortedDictionary? At least System management could break the 64 count limit KellanHiggins met some days ago? The starwars demo game shold get a new base since XNA is highly outdated now and MS do not even think about a revive of it.

GrafSeismo commented 8 years ago

I do not agree with not updating nuget, it is most comfortable to use it in nuget if you want to make some quick tests. The easyness in handling the framework is not equal to implement source. At least when we talk about this project is finished, why not releasing a final nuget package then?

KellanHiggins commented 8 years ago

Those changes seem reasonable. The 64 count limit has been fixed and merged in I believe.

I think SortedDictionary is slower than the Bag system. Anyone know if this is true?

What is MonoGame?

GrafSeismo commented 8 years ago

The limit is 64 now, but with dictionary you whould not have any limit in count but memory.

Bag is similar to array speed with some extras. We use it already for time critical parts and it would not make the butter no parsnips.

MonoGame (http://www.monogame.net/) is the multi-platfom implementation of XNA, but not with the complete set of features due to missing support on linux/mac/android for XAudio2 and some other DX related stuff. MS itself adviced developers to move to monogame or unity. I tried to move to monogame but ended with the insight that monogame does not meet my needs and vision of quality. So i start from scratch in UAP now with SharpDX.

thelinuxlich commented 8 years ago

Although the example(StarWarrior) is written with XNA, Artemis itself isn't tied to it. I'm okay with changing to SortedDictionary if it doesn't trigger GC during the game.

Maximusya commented 8 years ago

Int32, Int64, BigInteger are for bitset-operations (checking Aspect (TypeBits) and belonging to a particular System (SystemBits)) - how would you suggest to replace this with a Dictionary?

As for Bag vs *Dictionary - it could possibly be abstracted (or decorated) and presented to end developer as an option (speed vs memory requirements)

GrafSeismo commented 8 years ago

I suggest to use an identifier like the name of a class and get the System with it out of for e.g. a *Dictionary<TypeName, Type> or you reference <entity.Id, SystemName>

Well i guess a *Dictionary to host Systems in a 100 Systems Project is definitely not the bottleneck... At least when you hit speed critical range than, why not using c or c++ for that part? The overall special is the unpredictable GC wich ended with WinRT...

And please bear in mind, with .NET Core we have a totally new base, so old rules of performace have to be retested anyway.