Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


TheComet

Member Since 02 Oct 2013
Offline Last Active Yesterday, 06:09 AM

Posts I've Made

In Topic: Funniest line of code ever ?

28 November 2014 - 06:49 AM

 

Found this on TIGSource, and yes, it compiles and works as intended:

switch(mode)
{
    case(0): if(test(a, b))
             {
    case(1):     result = foo(a, b);
                 break;
             }
             else
             {
    case(2):     result = bar(a, b);
                 break;
             }
}

Duff's device seems to use a similar mechanism to "jump" into a location of code.

 

[EDIT] Whoops, just saw that someone already linked that (indirectly). Oh well.


In Topic: Best comment ever

28 November 2014 - 06:43 AM

These are hilarious. During my undergrad I was working on a partner project and found this in a 20 line .c file:

;;;;;  ;;;;;;  ;;      ;; ;;             ;;;;;;;  ;;;;;;;  ;;       ;;;;;;;  ;;   ;;  ;;;;; 
;;     ;;      ;;;;  ;;;;                ;;       ;;   ;;  ;;       ;;   ;;  ;;;  ;;  ;;   
;;;;;  ;;;;;;  ;;  ;;  ;; ;;   ;;;;;;    ;;       ;;   ;;  ;;       ;;   ;;  ;; ; ;;  ;;;;;
   ;;  ;;      ;;      ;; ;;             ;;       ;;   ;;  ;;       ;;   ;;  ;;  ;;;     ;;
;;;;;  ;;;;;;  ;;      ;; ;;             ;;;;;;;  ;;;;;;;  ;;;;;;;  ;;;;;;;  ;;   ;;  ;;;;;

Which much to my surprise compiles just fine.

(;) is a null statement and usually compiles to nothing at all.

 

A compiler I was working with for programming MSP430 microcontrollers would interpret a null statement as an actual NOP instruction. If I had pasted that thing into our code a lot of people would have been mad.


In Topic: Problem with A*

07 November 2014 - 05:43 AM

for(unsigned int i=0; i < openList.size(); i++)

It's never a good idea to iterate a container AND modify it at the same time. Elements can become invalid.

 

According to the Wikipedia article, you should loop while the openList is not empty:

while(openList.size())  // instead of while(!foundFinish)
{
    // pathfinding stuff here
}

I also don't see you ever remove anything from the openList. You've commented that part of your code out:

//openList.erase(openList.begin());

In Topic: Entity component system: data locality vs. templates

05 November 2014 - 04:52 AM

I'm not sure where this would become handy. Maybe if you make some basic AI system, then you can make some other AI system based on the first one, but overriding certain behaviour? Then you would end up with kind of mix of component and object-oriented design.

 

Basically, yes. Another example from my game would be an input system:

m_World.getSystemManager().addPolymorphicSystem<InputInterface, SDLInput>();

You can dynamically (or statically) switch in and out various input managers (I have another IOSInput class, for instance) without having to change any other code in the process. The other systems will still be able to call getSystem<InputInterface>() without knowing about the implementation change.

 

I don't really agree with this. If you are making a game with OpenGL/Direct3D, the rendering system will want all renderable entities at the same time. You go through the entities and build a list of draw batches from them. then sort the list by render states (shader, texture, VAO) and then render the sorted list. If the render system gets one entity at a time, this is not possible, at least directly. Also, if you have thousands of objects, there will be a lot of methods calls.

 

That's a good point.

 

I think I'll add that functionality to Ontology, thanks for pointing that out.

 

Another approach: Wouldn't it be possible to split the various stages up into systems? I.e.

  • BuildDrawBatchSystem would group the renderable entities together into various groups
  • SortRenderStatesSystem would sort the lists into render states
  • RenderSystem would finally render everything

You could pass the lists around via an entity or just communicate it directly between systems.

 

The downside of course is the function call overhead of processEntity().

 

I wrote Ontology mainly as a learning experience and with a naive approach. In my experience, it's not that hard to do, so maybe you'd want to write a specialised ECS for your render system? That way you can tailor it to your exact needs.


In Topic: Thread-post never made ... almost

04 November 2014 - 04:28 PM

Well excuse me princess, I'm sorry for helping you.


PARTNERS