Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Online Last Active Today, 05:58 PM

#5301647 Is It Really That Nonsensically Impossible To Have A Successful First Game Pr...

Posted by on 20 July 2016 - 05:59 PM

 Is It Really That Nonsensically Impossible To Have A Successful First Game Project?


Its not impossible. If thats what you wanted to hear. You can most certainly come up with a contrived scenario in which such thing would be possible, but that would only prove your imagination skills rather than the probability of actual "success".


I dont really know what you're asking here. You know what we mean when we say "your first project will fail". You know that discussing possible/impossible is just semantics. There is nothing to discuss really.

#5301095 Dx11 Renderstate

Posted by on 17 July 2016 - 11:38 AM

Moreover, think that you wont have *that* many crazy combinations of state. The APIs tend to be way, way more flexible than what you really need. Its not about providing everything the API allows you to do, but to restrict it to an useful subset of features.


With all render passes and materials known before hand (and you will know them), you can easily create all the state objects you'll need. After that you can proceed like Mathias suggested, switching them (whole) as necessary.

#5300902 Texture Disappears When I Load Any Type Of Shader (Lighting Shader In This Case)

Posted by on 15 July 2016 - 10:27 AM

Disable the shader program after rendering whatever you want to render with it. Afaik binding a shader program disables all the fixed function pipeline stuff, you're binding it once and never unbinding it. Further draw calls will all be made with that program.


Doing that kinda mix and match of fixed function and programmable pipelines will end up in such issues. You should strive to use either one or the other. Preferably the latter. If you dont want to deal with such hassles, you can always grab a rendering engine that does it for you.

#5300807 Slavery, Include Or Not?

Posted by on 14 July 2016 - 06:16 PM

Eh, a quite popular game, Mount & Blade, which spawned sequels (the more polished M&B Warband, upcoming M&B 2) and spinoffs (M&B Viking Conquest, M&B Napoleonic Wars, etc) has "slavery".


You can just capture people at the end of each battle. Sell them to "slave drivers" in the cities, which gladly tell you exactly what they do with the people (ask for ransom, if no relative pays up, sell them as slaves somewhere). Literally no actual consequence beyond maybe some companions (iirc) kinda disliking it. But thats it. Its a nice source of gold in the early game.


No one ever batted an eye at it.


How fucked up is everything that you have to think about including slavery or not in a game about ships, set in the Caribbean, in the 1600s of all times. Of course there is going to be slavery. Thats half the reason those ships are there in the first place! If you want to pretend it never existed I'd choose a different setup or time period, maybe fictitious happy archipelago where all you trade is fruit and rainbows or something. Throw in some gnomes/elves and stuff so no one doubts its fantasy.

#5299254 Questions about Autotiling []

Posted by on 05 July 2016 - 07:25 PM

First and foremost. That demo is really nice. Like the attack feels like it has impact, the movement is just right. Really like it!


Second, maybe its just me but could you share how you draw your scene? I'm not terribly sure how I'd implement tiling without seeing how you draw stuff.


For instance, if you got a sort of matrix structure of tiles, you could just set the floor last, so do a loop with an "if (empty) { //set as floor }".


The tile itself, the texture, should be seamless, which means if you put one next to the other, it should look continuous. How are the levels defined? For example, if they're on a separate structure, it shouldnt be too hard to make a tiny editor that lets you paint tiles with floor textures, and then just send the tiles to render, which already will look seamless.

#5299079 Creating Entities from XML in a Data-Oriented ECS

Posted by on 04 July 2016 - 10:01 PM

I dont like the "system owns its components" approach. More often enough turns out that going that way, multiple systems end up needing to "own" the same component store (everything needs to know an entity's position for example). And managing those dependencies becomes messy.


I prefer to separate it in two:

  1. Component stores know one component type, and manage how they get stored and how a component is mapped to an entity.
  2. Systems request the store they need, they dont "own" the components, they just operate on them based on the entities they're processing.

In my ECS a "World" instance knows all the entity systems, the entity manager (that shells out entity ids) and the component manager (that shells out component stores). That way in an "init" step on the World instance, all the dependencies (both component stores and other systems) can be injected in all the systems that request them.


This way a system doesn't has to do all the steps of managing the component's store memory, the entity -> component mapping and whatever processing step it needs to do (input, ai, physics, etc). Stores manage memory the way they see fit (sometimes you need a possibly wasteful but cache-friendly flat array, sometimes an unordered map works well enough), and the system just knows how to ask the stores "hey, give me the components of this entity I have here" to process them.


I've made it so I can have stuff like:

// Beware of Xtend code
class RenderQueuingSystem extends EntitySystem {
  /* All of these get injected at runtime. */
  // This is a dependency on other entity system.
  var RenderSystem renderSystem;
  // These are dependencies on component stores.
  var ComponentHandler<Geometry> geometries;
  var ComponentHandler<Spatial> spatials;
  var ComponentHandler<Material> materials;
  override processEntities(IntBag entities) {
    for(int i = 0; i < entities.size(); ++i) {
      val entityId = entities.get(i);
      // Fetch components of the entity.
      val g = geometries.get(entityId);
      val s = spatials.get(entityId);
      val m = materials.get(entityId);
      // Do the required processing.
      val renderTask = constructTaskWithComponents(g, s, m);
      // Later when RenderSystem gets processed, it will be drawn.

Actual filtering of entities that the RenderQueuingSystem is done in a pre-process step, where the system gets notified each time an entity is added/removed, so it can build a list of entities it knows they meet the required component criteria. Thus why no "if it really has" check when fetching a component from the store.


Beyond that, entity loading goes beyond the scope of the system. I use a YAML lib to load entity template definitions from a file, compose a new entity out of the components, then add it to the World instance (which feeds it into the game). Notice I never mention any "system" in this process, the system only gets notified of the entity's existence when its added to the World. I guess in your case, if you want fine grained control on component allocation, the de-serializer should know the component stores so it can ask for new component instances when loading an entity template/prefab.


I think all of those concerns (component stores, entity-component mapping, component serialization and deserialization) should be separate. Otherwise you'll end up with fat systems with too many responsibilities.


For reference this is how a YAML entity template looks like:

- !Geometry
  name: cube.internal
- !Material
  diffuse: mossy_rock_02.dds
  normal: mossy_rock_04.n.dds
  shininess: 127.0
- !Spatial
  scale: 2.0
  type: STATIC
- !StaticPhysics
  param0: 1.0
  param1: 1.0
  param2: 1.0
  shape: BOX
- !StaticShadow {}

From there a list of ComponentTemplate is loaded, each knows how to create an instance of a component with those specific parameters. So an "entity template" is just a list of ComponentTemplate objects.
Its not a very good reference since my serialization is very, very green (ie, thats just prefabs/templates, not even dealing with scene serialization yet). Although it might give you ideas (like for instance, not using XML :P ). 
EDIT: Ugh editor eating text after that last code tags. Its awful.

#5299073 Unity vs Unreal Physics for driving game

Posted by on 04 July 2016 - 07:41 PM

Yep, both use PhysX. So you wont be choosing based on that alone.

#5298819 Does adding Delegates/Function pointers to an entity break ECS ideology?

Posted by on 02 July 2016 - 12:52 PM

Well a delegate is data, so that fits your description. A "CallDelegateOnConditionMet" system would have components containing game-state conditions to check, and delegates for the system to call when those conditions have been met :lol:

And the next logical step is to have a "VTable" component to stuff your function pointers in, then re-implement inheritance through it :P

#5298743 Does adding Delegates/Function pointers to an entity break ECS ideology?

Posted by on 01 July 2016 - 03:30 PM

I'd say "pure ECS ideology" means: Entity doesn't has any logic, and components either. Logic goes into your systems. Entities are IDs, components are data, systems have all the logic. End of story.


So you wouldn't do any of what you mentioned (neither adding functions to an entity nor adding functions to a component).

#5298742 Creating OpenGL context in different OpenGL driver versions

Posted by on 01 July 2016 - 03:19 PM

Do yourself a favor and use GLFW, or SDL to handle contexts. No one will look down on you for not learning all that platform specific stuff, and if they do, they're idiots, so you shouldn't listen to them anyway.

#5297768 Is there any reason to prefer procedural programming over OOP

Posted by on 23 June 2016 - 07:33 PM

Don't look at me. I think the "but but I have to type "static" and put it in a class file!" complaint is stupid. If it looks like a duck and quacks like a duck... C# has exactly the same requirements thus why I dont see the point.

#5297764 Is there any reason to prefer procedural programming over OOP

Posted by on 23 June 2016 - 06:42 PM

All right, lets see...


You cannot do procedural programming in Java


You can't do it in C# either yet you use it as an example.



Writing a simple 'Hello World' program in Java isn't contrived OOP as an exercise, its contrived OOP because that's what the language demands.

Yes, thats true because it isn't a language designed to make "Hello world" programs. If all you want is to write short "Hello world" programs I'd recommend something else, like just make an HTML label tag and open it with a browser.


 We can agree though, that most early programming habits anyone picks up in any language are best to hit the dustbin sooner than later. Rarely are first habits good habits.
 Of course.


it just so happens that among those goals are enforcing a particular and rigid view of OOP best-practices, protecting fully-functioning programmers from themselves, and a misguided attempt to make Java programmers interchangeable by creating a language that forces them into the lowest-common denominator.  
And why don't you say the same of say, Python which heavily discourages implementing your own data structures by ubiquitously using their own and having special syntax only for that purpose? Why dont you say the same of JavaScript from which until very recently was confined to be a browser scripting language? Why single out Java as the dogmatic example in the age where all the most used languages, except very few exceptions, are just as opinionated, or even more?


You could say that of most of modern languages. Nevermind the recent wave of people advocating even more religiously opinionated languages in the functional paradigm. Fixating on Java seems such a 90s thing to do. Where the concept was relatively new. Python was new, JavaScript was new. C and C++ were the way of making applications. Nowadays? Makes no sense, but I see people repeating it again and again.


IMO, C# did a much better job achieving Java's technical goals, and was better for throwing off as much dogma as it could.


Have you ever developed an application in .NET? Language is fine, (and practically Java in PascalCase 90% of the time regardless of what most C# purists say) but the ecosystem is centered around Bill Gates butt. I dont even know how could you paint it as the "least dogmatic" of the two.


Yeah, its the "least dogmatic" if you already use Visual Studio all day and deploy to a Windows Server computer every day, and only do fat destkop clients for Windows 7+ in WPF. As soon as you get out of that tiny cage you're thrown to the wolves. GUI solutions for other platforms are broken. Web solutions for other platforms are either broken (Xamarin) or in alpha stage (.NET Core). Nevermind finding tools to help you out in that endeavor because there is like only one half assed IDE out there that manages to understand C# and Linux/OSX at the same time.


Yeah C/C++ are not very dogmatic, but people are constantly trying to replace them with more dogmatic equivalents (Rust, Go among others), and C# is Microsoft's eco system baby and barely knows how to crawl anywhere else, nevermind the fact that C# 7 stuff and above are very, very close into making it a kitchen sink of features like C++ is.


I'm just not seeing your counter examples at all man.

#5297757 Best Java Engine?

Posted by on 23 June 2016 - 05:36 PM

LWJGL isn't an engine. Its "just" provides bindings to OpenGL, OpenAL, and a couple of assorted libraries (jemalloc, nanovg, nuklear, etc). Fairly similar to starting from scratch in C++. The developer knows what he is doing, and its really nice stuff only if you want to start from scratch, and probably never finish anything.


jMonkeyEngine is a "proper" engine. With a GUI editor (last time I checked), and all systems (animations, ai, terrain, graphics, physics, etc) you need to make a game.


libGDX is more of a "framework", all the code, systems and infrastructure you need to start making a game, but code only. There are other projects that build editors on top of it.


As for something really on par with Unity but made in Java, nothing really. Big name engines are made in C++ with various scripting layers on top of it. I've seen Lua, C#, Python and C++ itself as "scripting" layers, but not Java (90% sure because native interop with Java is a PITA, and general distrust of Java as a language for doing anything making games).


There are possibly hundreds of mobile games made with libGDX, and a bunch made with jMonkeyEngine. LWJGL powers the rendering backends of both.

#5297359 Is there any reason to prefer procedural programming over OOP

Posted by on 20 June 2016 - 02:18 PM

One problem is that the style of OOP taught in many colleges, universities, and books borrows very heavily from Java's over-orthodox view of what OOP is.


Eh no. What you find in universities are a lot of people who are not exposed to codebases beyond the really basics they teach in the courses. They read software engineering books (that are for the most part, language agnostic, and UML centered), and try to apply that to their "hello world" examples. Results are obviously disastrous since software engineering books are targeted at big organizations, with big codebases, and with complex projects, often much more complex than whatever the professor has ever done.


There is a lot of awful code written in Python by people who particularly dont like coding at all, just are doing some research project and want calculations done, heard of "numpy" and started using it. Yet you wouldn't declare that kind of code a reference for what coding in Python is. Neither would you declare the kind of C code produced in introductory courses the reference as how C is done. At least I wouldn't.


Worst of all is that people get out of those courses thinking "This is how Java is done!" "This is how C is done!" and dont understand that no, even if all you did in the introductory course is to make CLI applications, it doesnt means you cant do a GUI in C/Pascal/structured language X. And that no, even if all you did in the OOP course is to make InterfaceX and InterfaceXImpl interfaces/classes respectively, it doesnt means thats how you code things in Java/C#/OOP language X.


 Having learned Java-style OOP hasa lasting effect on a programmer. Its like an embarrassing accent
Whereas Zee Plus Plus was given to us, unworthy mortals, from the hand of God, through the visions of Prophet Bjarne Stroustrup himself. Teaching us the One True Language To Rule Them All. Obviously. Just look at Boost.

#5297158 Trying to remove bullets and get 'java.util.ConcurrentModificationExcepti...

Posted by on 18 June 2016 - 07:06 PM

I'd use Aldacron's method, it should be faster.


Actually, after looking at removeIf implementation, Oberon's method could be even faster.

  1. GlassKnife's method does a first pass looking for elements, then a linear search through the array every time it needs to remove each element inside 'removeAll'.
  2. Aldacron's method does a single pass, but it needs two "long lived" lists and copying the element's references around.
  3. Oberon's does a single pass, and it only uses internally a short lived BitSet, which will probably be ruled out by escape analysis.

I'd go with 3 if Java 8 is available, otherwise with 2.


EDIT: Ohh dude, you're calling remove twice probably. Duh. 

for(Iterator<Bullet> it = bullet.iterator(); it.hasNext(); bullet = it.next()) {
 if(bullet.rectangleBullet.x > screenSize || bullet.rectangleBullet.x < 0) {

Doing two ifs separately there makes it so you'll be calling 'remove' twice for bullets that meet both conditions. That throws an error obviously since you can't remove the same element twice. So you should remove once if it meets any of the two conditions.