Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Feb 2012
Offline Last Active Feb 13 2016 07:45 AM

Posts I've Made

In Topic: Cell based game and collisions in discrete space

04 January 2016 - 02:55 AM

Make one pass to mark objects that want to move as no longer being on the space where they are (calling them “hovering”).
This leaves the space open and others can move into it.

The only problem is that a piece that is hovering may not be able to go where it wants to go, yet can’t land back on its square because it has been stolen.
This is easy to solve, though it involves a small amount of recursion.

When a piece wants to move to a square, if the square is empty (and all other rules obeyed), FinalizeMove(ThatPiece) (remove hovering flag, piece is finalized on the new square, is done processing for that frame, cannot be looked up by the following routines).
If the square, however, has a piece hovering over it, recursively evaluate the piece that is hovering. You terminate the recursion when a piece can move to a square or when you reach any of the pieces that are currently being checked in this recursive call.
This means the pieces rely on each other, and all moves they are trying to make are valid. In this case FinalizeMove() on each piece in the recursive call.
In other words, if any fail, don’t move any of the pieces.
If they all pass, move them all.

L. Spiro


Thanks -- a nice "KISS" method for doing this. I had tried something similar, I believe, but did not use the flag grid, which seems better.

In Topic: Programming "Widgets": how do you efficiently draw/redraw windows and...

22 December 2015 - 12:10 AM


I don't understand what you're talking about with the overlap. Do you mean draggable windows that float over other windows?

Overlap means yes, windows/widgets overlapping on top of each other. Not necessarily draggable -- just on top of each other, e.g. a menu and then you open up a sub-menu which floats above.

In Topic: Event Handling within an ECS

20 December 2015 - 09:21 PM

@Servant of the Lord: Thanks a lot. I think I grasp now how this works. It certainly seems more flexible than trying to shoehorn everything into the "update" routine, probably is more amenable to optimization as well. You don't have to worry so much about trying to fit the system effect to a strict sequencing regiment, either.

In Topic: Messages and dynamic memory

20 December 2015 - 06:55 PM


Why would we serialize messages? This is about internal communication within the program.


Because it provides one solution to your problem. You can allocate a single block of memory and messages and write themselves into the buffer, etc...


First, I'd make sure you really need a messaging system anyway. Ideally you could replace them with method calls, and that would make the dependencies more clear.


If you really do need some sort of message-like design though (for instance, to be able to queue up messages and process them later), then ask yourself if dynamic allocation will really be a problem (I assume you're worried about performance of dynamic allocation).



Yes, I suppose that you could just use method calls, e.g. inherit from some kind of interface class which is kept suitably loose that implementation details don't leak, but then you can't defer processing until later, which was the purpose of the messaging system.

In Topic: Messages and dynamic memory

20 December 2015 - 08:16 AM

Well you can send different size messages if theyre prefixed with a size or type.


Like serialize size followed by data (probably the raw memory) in a queue of bytes, and on the other end read the object into contiguous memory (since std::queue is not contiguous) and interpret the address as a Base*.


But unless you actually need something like that for performance reasons, I wouldnt do it because it seems a bit prone to bugs. Maybe if you do proper serialization instead of raw memcpy (or use POD types + switch instead of inheritance) its safer... (does c++ even allow raw memory copy of objects with virtuals?)


Why would we serialize messages? This is about internal communication within the program.