Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Offline Last Active Yesterday, 03:31 PM

#5312175 Why C# all of a sudden?

Posted by on 23 September 2016 - 04:02 PM

Well, yes and no. IIRC, the official implementation was closed indeed, but it was standardized from an early age and all blocking patents were released under some "community promise". So it was an open language with a closed implementation. I think Java was a closed language at the time, not even sure if an open implementation existed. There was some shared source reference implementation of .NET ("SSCLR" or something), but the license was bad.


Originally Microsoft implemented all of Java and then some. Delegates for example appeared first on Microsoft's Java, which was against the licence Sun offered (they wanted a more centralized development where they agree on certain features and get them standardized first). They literally tried to do the embrace-extend part, but Sun's lawsuit came before the third step. Still Sun fucked it up by themselves by stagnating the language for years (although not so much JVM as a platform, thus why tons of alternative languages have sprouted from it).




What changed? Why is C# or JITs (or for whatever reason Java and C# were hated) acceptable, now?

Because it isnt like they coded a VM once back in 1992 and set it in stone. Java wasn't even JIT'd when it started, that came later with HotSpot. VMs have advanced a *lot* in the last 20 years. HotSpot in particular has tons of nifty profile guided optimizations that does on the fly (branch prunning and reordering, "devirtualization" of method calls, escape analysis, etc).


Microsoft's VM isnt as sophisticated, but it was better designed from the get go, so you got less overhead with native interop, easy marshaling between native and managed memory, finer control of the memory layout of your objects via structs and arrays of structs, etc. ie, most of the tools you need to get more performance out of your code.


Google's V8 can get quite nice speed out of JS in record time since its been based on the goal of fast loading websites (afaik JS VMs do cool stuff like optimistic typing to try to get around JS's limited type system).


Not only hardware is faster but VMs are much better at what they do nowadays. Nevermind that the tooling and environment is really great (for both C# and Java you got great IDEs, great libraries, great debugging tools, great profiling tools, etc).

#5312172 Gui Libraries?

Posted by on 23 September 2016 - 03:43 PM

Having your UI lib issuing GL commands mean the user has to track all the state your library modifies, or needs before rendering. OpenGL is a state machine, which means that your lib not only needs the state it sets, but it also implicitly needs all of the state it doesnt touches in certain ways. Its a pain in the ass to work with and a pain in the ass to debug. Just issue commands and let the game's renderer do its thing. You can see nuklear or libRocket's rendering APIs as an example.

#5311310 Engine works fine on Ubuntu but has issues on Windows

Posted by on 18 September 2016 - 12:14 PM

Yeah Intel stuff in Windows didn't get good until the GL 4.2+ GPUs started to come out. If you have no issues with maintaining a D3D pipeline, thats prolly your best option. Otherwise just target core 3.3 on both platforms and scrap older Intel GPUs on Windows.


AMD supported GL3 cards up to GL 4.2, so you get a couple of nice GL4 extensions supported in GL3 hardware (arb_shading_language_420pack, arb_texture_storage, etc). nVidia went a bit further (you can find 4.4 extensions in GL3 cards). Intel just implements what it wants on Windows (sometimes GL 3.1, sometimes GL 4.1, sometimes GL 4.2, its a lottery). Although on Linux they do support some GL4 extensions on GL3 hardware.


Thus why GL 3.3 core is a nice "middle ground" context to target on most places.

#5311131 Data-Driven Renderer - how to modify the pipeline on-the-fly?

Posted by on 16 September 2016 - 03:42 PM

1) What is the cleanest way to allow on-the-fly modification of the rendering pipeline in a data-driven graphics engine?
 Reload everything?


 2) How should render targets be described in a flexible rendering pipeline? How to specify that a render target should be taken from a render target pool?
I put a "shared" flag in each render target. If they're shared, they go to a name->target map. All targets first look into that map to see if there is a target with the same id, or create it otherwise. If a target is created and it has the shared flag, I add it to the pool, otherwise I just leave it alone in the render pass.

#5309412 (VB) Barcode Reading / Scanning for Inventory?

Posted by on 04 September 2016 - 01:15 PM

You could just google for anything like that. Its a fairly common application to make. I got like 10 different applications from googling "inventory barcode software".

#5309339 Faster Sin and Cos

Posted by on 03 September 2016 - 05:43 PM

  If that's true, you could probably remove the branch entirely
Or wrap around the "i32I & 1" one bit to the right then use that to flip _fX's sign bit accordingly.


In any case, no branch is faster than branch on my end (using doubles).

#5309303 Faster Sin and Cos

Posted by on 03 September 2016 - 09:09 AM

One question, why put all those muls/adds in that last branch if they (seem) to be the same for both paths? (except for the "- x *" and "x *" parts). Or I am missing something here?

#5308261 defend sacred animals quest

Posted by on 27 August 2016 - 02:07 PM

Suggestions? Well, let the player join the hunters and kill the animals, getting something in return. Or dont join the hunters and let the player kill the animals for themselves (sell the pelts or something). Or let the player kill everything and everyone for no reason. Those should all be properly handled and possible quest outcomes. 


Nothing screams RPG to me more than getting a "Bandits are attacking our village, help us!" quest, then going to the bandits and joining them in the raid.

#5308135 Enums don't have their own variables?

Posted by on 26 August 2016 - 06:45 PM

 It would never occur to me to do something like this in C#

Because you can't. In C#, enums are a thin typesafe shim over integer types. In Java they're full blown objects. Not only can you put fields and methods in enums, but you can also have different overrides in each value of a particular enum. They cant extend classes because they already implicitly extend Enum, but they can implement interfaces.

#5306899 Engine design v0.3, classes and systems. thoughts?

Posted by on 20 August 2016 - 11:19 AM

The input handler. Seems very, very thin for what would you expect (keyboard, mouse, button handling, analog input handling, etc). I have no idea what a "CTimer" is nor why its so important that you need it in the diagram.

What about event handling? If the player runs over a trigger, which system is in charge of calling that event handler? If a player runs over a metal plate how does the audio systems knows how to switch the step sounds?

Im not quite understanding the "Actor" thing. Is it supposed to be heavily WIP? Because I'm missing things like game logic, triggers, scripts, quests/missions, AI, etc.

Not sure in D3D land but at least in GL land I have a single GLSLShader class that can be vertex, geometry or fragment shader. The only difference is a type enum just to know what it is.

I *think* that if you want to do a high level design of an engine, you'll have to start smaller first. Try only with the renderer, since thats the most detailed part of the diagram, I guess thats the part you're most familiar with. Other parts (events, scripting, AI, more complex game logic) it looks like you'll have to discover on your own, and only after you learn more about them you'll be able to design for it.

#5306004 Is The "entity" Of Ecs Really Necessary?

Posted by on 15 August 2016 - 11:58 AM

That just moves the problem into a new place, and gives you 2 headaches (how do I carve my game up into orthogonal systems and components) instead of one (how do I carve my actors up into components).
Its a "headache" that separates the concerns better. It separates component ownership better. It separates component usages better. It separates the system dependencies better. If separating concerns is multiple headaches for you, then put everything in a god class. Only one big headache there.


I already listed the kind of issues you have to think  when stuffing the logic in the components. Moreover I already listed the issues people come here with when they do so. I'm just not seeing your POV here. Could you explain further the "two headaches" you mention?


I don't think we should accept that one particular definition gets to be called "Entity Component System" and other approaches, which also have entities and components, do not.
Then don't complain latter than there isn't a "clear definition" of what an ECS is. Its like handing you a MVC definition, then saying you dont like it because there are other architectures that use models and views, but not controllers. I know, thats why its called MVC, not MV.


I agree on the "Entity System" label though. It is vague, and stupid. Quite hard to come up with an architecture in a game that doesn't uses some form of entity, actor, or similar.

#5305775 render huge amount of objects

Posted by on 14 August 2016 - 12:08 PM

What cozzie said. Not all 66ms of work are born equal. 66ms of work on a GTX 980 isnt the same as 66ms of work on an Intel HD 2000.

#5305561 Interfaces and code duplication

Posted by on 12 August 2016 - 04:52 PM

If you want to buy into the ECS variant of all this (e.g. where your components are just inert data) there's also the classic Artemis library for Java that got popularized around the same time as previous article.


That site went offline a while ago, I dont think whoever picked it up is actually the original Artemis developer. Just look at the other posts in there.


This is what I'd use: https://github.com/junkdog/artemis-odb Its a fork of Artemis, much further developed. Original Artemis had a bunch of bugs and issues, was pretty much abandoned after a while. It spawned tons of forks though. I have my own (in my signature!), but artemis-odb is probably the most developed and widely used right now (and they support Android).

#5305555 Is The "entity" Of Ecs Really Necessary?

Posted by on 12 August 2016 - 04:25 PM

That particular strict form of ECS is basically just relational data modelling, rediscovered, without the rigor or flexibility.
Eh no. Because you have a one to many relationship model between entities and components it doesnt means its relational. Unless you focus on a very tiny aspect, in which case the comparison would be meaningless, an object with a list of things would be "relational modelling" with the same criteria. Specially since relational models are about data, not behavior. As I said, ECS tackles behavior.


For the most part, whether your logic is in a system or in the component is just syntactic sugar and makes no functional difference
Yeah, in the same way as the lack of functional difference you'd have by say, writing your entire game in a single function. Functionally, they're the same. You'll still see pretty pictures on the screen.


Having logic in the components themselves means that components will need to know about other kinds of components, or about all of the other components of the same type. And you end up with these kinds of questions in the forums "What do I put in my components?" "How can I make component X relate to component Y?" "Omg I cant make the component logic isolated from other components! ECS sucks!". What if the same component is used for two different things? You just shoehorn the two different functions in the component and call it a day? It opens a whole can of worms.


The "system" part deals with that issue, providing a platform where you can place these dependencies between components and between entities. Systems know about entities, know about other components, and know about other systems. It is the place where you solve your data passing and communication issues.


Most of the component handling issues I see being asked in this forum stem from forgetting what systems have to do, and making components and entities do more than they're supposed to. So you end up having components having to know about other components, systems managing components and having to share them among other systems, which ends up in fighting hard with which system owns what components, and other kind of issues that shouldn't be really there if you follow ECS strictly. Then you end up with people implementing event systems for all the apparent shortcomings of ECS, and just pumping the data through there.


BTW The T-Machine blog is one of the many that give a dishonest comparison between (bad/incorrect-)OO and their flavor of ECS
 Thats irrelevant. I did not argue with that point. I just said T-Machine blog is a nice source to learn what an ECS is, not what is good for. If it pairs it against bad OO or whatever is irrelevant for that purpose.

#5303360 Ecs Architecture Efficiency

Posted by on 31 July 2016 - 02:19 PM

My guess is that he is asking for the "throughput" of the framework.


ie, how many entities you can add/remove from the world per frame while not dipping below 60 fps. Same with attaching/removing components. The raw overhead of the framework you pay for having it track all of this stuff.


The answers you get are because its not an easy thing to measure in "proper" game engines and games. Its an easy thing to do in our tiny hobby projects that dont uses complex resource management sub systems, nor complex sub system initialization steps. Not so much on bigger games and engines.


I'm going to throw a reasonable guess out there that most of the time on fully featured games (with sound, graphics, ai, etc), entity handling overhead is quite tiny compared to all the other complex stuff the engine has to do (manage disc resources, upload to gpu, insert the new data on the various structures the AI/terrain/sound systems use, etc).


Ideally in an ECS the cost of doing all of these operations (entity insertion/removal, component insertion/removal, entity iteration, per sub system filtering of entities based on their components) should be low enough for you not having to worry about if you're mutating the structure of too many entities, or if you're creating/removing too many entities in a single frame. As the game's inherent complexity goes up, this (probably fixed) overhead becomes much more less relevant.


What is to say: The cost of adding an entity to the world is going to be relatively much bigger in a 2D space invaders game, compared against the same cost in the context of a more complex game, like Battlefield for example. Simply because in Battlefield you might be processing 10Mb worth of data for loading an NPC into the scene, so a couple of hash lookups for making that NPC appear in the world managed by the ECS is not a lot.


In short, its not an appropriate question without having it placed in the context of a specific game.