Sub's coding pool party

[sub]

You had recommended me a few books that I picked up to help me with the design / structure of a program, still trying to wrap my head around good / proper ways to do things to be honest. The hardest thing for me about programming is knowing how to structure a project that's more long term. One of the reasons I like the idea of components is that it seems more malleable, you don't have to plan and account for the entire design at the beginning, I'd have no chance for success if I were required to.

 

[Shonnie]

Sounds elegant, but the disadvantage is that this does not seem to be able to handle multi-threading. You can not have your physics system update the positions in one thread while the render system renders in another thread (reading the positions), 'cause the positions might be in a inconsistent state if the render thread reads them while the physics thread is still busy updating them. The whole thing sounds kinda like a blackboard system http://en.wikipedia.org/wiki/Blackboard_system to me; for that there is a lot of software for that that already solves thinks like multithreaded access.

Wouldn't it be possible to just use half of the objects on one thread and the other on the rest? Example:

1. Count the amount of velocity-objects you have.
2. Split them onto 2 lists
3. Run a thread on each list.

Right?

 

[sub]

I think you'd want to update most objects of the same type (such as all the velocity objects) at the same time. The number of those objects wouldn't be constant, but that probably doesn't matter too much.

 

[Shonnie]

Yea you're right. Wouldn't work out having only half of the stuff moving when the other thread starts going to sleep.

 

[harSens]

Wouldn't it be possible to just use half of the objects on one thread and the other on the rest? Example:

1. Count the amount of velocity-objects you have.
2. Split them onto 2 lists
3. Run a thread on each list.

Right?

That can only be done trivially if the movement of each object is independent of that of other objects, which is typically not the case in physical simulation (objects can collide, lay on top of each other).

If you use separate threads for rendering and physical simulation you can potentially get more frames out, even if rendering has to wait for physical simulation to be finished, since you can do part of the physical simulation while the new frame is being rendered. So like this:

thread 1|Physical Simulation|Render|Physical Simulation|Render|Physical Simulation|Render|Physical Simulation|Render|
time->

vs

thread 1|Physical Simulation|Physical Simulation|Physical Simulation|Physical Simulation|Physical Simulation|
thread 2                    |Render|            |Render|            |Render|            |Render| 
time->

 

[Shonnie]

harSens! Thank you!

Yea that made it even more clear. So one thread does the calculations for the up-coming frame.
While the other thread renders a frame with the last know completed calculations.

But wouldn't locking an object calculated in thread 1 so it can be used in thread 2 slow everything down?
Or is this just the way it is?

 

[sub]

Will this work?

The game Risk. User draws a basic map of any size on a png image, or whatever.

The game is able to load this image and use the map as the board, determining which territories are next to each other, and which territory the user clicks on.

In the image that the user draws
- Each individual territory will be defined by a unique color.
- The background color is off limits for territory color, as is the color black

When the game loads the image, it determines what territories are next to each other by doing the following
- Go over every pixel in the image pixel by pixel, line by line

• if color we haven't encountered yet and is a color other than the background color / black, register it as a territory and save what color is associated with this territory
• look at all neighboring pixels, and any color other than background/black will be defined as neighboring territory
  • if black pixel, again look at all neighboring pixels that we haven't yet visited and repeat above step. This is to allow for maps that have a thick black line, should have an arbitrary limit for the number of times this can be repeated for a black pixel

User has the option to make a second image to serve as a background image. If this is provided, the background color on the original image becomes transparent and the background image gets displayed during runtime, with the map image displayed over it

To determine where a user clicks, we'd get the pixel color on the map image for the xy of the mouse. If it matches one of our territories, we know we clicked there.

We can change any pixel of whatever color at runtime to show which nation owns what territory

--

I'm thinking that would work, but would there be a better way to do this?

 

[dutchmeat]

harSens! Thank you!

Yea that made it even more clear. So one thread does the calculations for the up-coming frame.
While the other thread renders a frame with the last know completed calculations.

But wouldn't locking an object calculated in thread 1 so it can be used in thread 2 slow everything down?
Or is this just the way it is?

I was wondering the exact same thing, do these objects have synchronizable variables which get's set on the next frame?

 

[harSens]

Yeah, in a typical setup you'd have a local copy of the state (position, rotation) of each object in the physics thread, and then copy the local state into a synchronized state at the end of the physical stimulation step. The render-thread copies the synchronized state to its local state before each render step and uses the local state to render. You can either have the render thread run continuously, which might mean that it renders the same scene twice, or you can have the render thread wait (meaning that other thread can use the cpu-core it was running on) for new results from the physics thread and have the physics thread notify the render thread (or simply all threads) when a new physics frame has been rendered.

 

[sub]

So I thought about it and I'm going to make Risk, but I'm going to do an easier approach than I described in the first post

- If you removed the names for the territories, this would be an example of a good map that would work in the game

• The only requisites for drawing the map is that it must be a .bmp, and each territory must be one solid, unique color so that the game can color the territories with the proper player color

- There's going to be a .ini file associated with each map that specifies how the game should treat the map, something like this (lines with a ; are comments and ignored by the .ini file)

[Map Info]
author = Sub
image = imagename.bmp

[Continents]
;Continent Name = How many additional troops you get for controlling all territories in the continent
North America = 5
South America = 4
etc = 2

[Territories]
;Territory Name, x location of a pixel belonging to this on the map, y location of a pixel belonging to this on the map, Connected to this territory, Connected to this territory, etc
;The xy pixel location is also going to be the location where the game places the text for how many armies are in that territory, so it should probably be around the center of that territory

East U.S., 43, 42, West U.S., Mexico
West U.S, 24, 50, East U.S., Mexico
Mexico, 90, 93, East U.S., West U.S., Venezuala
Venezuala, 90, 120, Mexico, etc.

--- edit ---

Does anyone want to make me a world map? I'll make the text file, I just can't draw for shit.

Otherwise, this abomination is going to be the map

 

[Shonnie]

No, my drawing is worse than that. Nice idea though. Like the color and pixel logic you throw in.

 

[sub]

All right, so I got some more time to work on this and I'm making some progress. Now if you click on a territory, it recognizes which territory you've clicked on and can change the color in that territory to whatever color you want.

http://i.imgur.com/kZbeNFM.png
http://i.imgur.com/knjsRdQ.png

Now going to work on getting the territories connected to each other, which should be pretty trivial I think.

 

[DaRkOwNs]

...is it weird that I'm seeing asses and breasts everywhere on those photos?

Sub, you and your thinly veiled rorschach tests.

 

[Horatio]

Looks good!

I made a blank map, here you go - http://i.imgur.com/BqsnGAP.png.

 

[sub]

Thanks man, that was really nice of you. It needed a little work (Not all countries were a solid color/I made a lot of border colors black), but it's in now and working. Check it out

I'm going to probably have to replace this eventually since it's taken from another game, but for now it's good.

 

[Horatio]

Hah, no problems!

The game really does look great, though! Can't wait to see the next stage!

 

[Almighty_Gir]

Sub, if you fancy a more advanced project any time, i've got something up my sleeve that i've been planning for a while. i was going to teach myself to program while i did it, but this will probably work out better.

 

[sub]

Working on this for like an hour here and there, it's still coming along.

You start up a game, choose the number of players / their colors (if you want), and then it randomly assigns each of those players territories and randomly distributes 10 armies to their territories. Eventually you'll have the option of starting a game and choosing specifically what territory you want / where to place your starting armies, but this is good for a quick start, and something of a quicker and more random start is how how I personally would rather play Risk.

Clicking on a territory selects it (right now the color just gets brightened -- West Africa is selected in the picture). Next I'm going to work on the attacking mechanisms, so clicking a territory with units on it, and then clicking a neighboring territory would initiate an attack.

 

[hleV]

My country ain't there. Curse you.

 

[sub]

Lithuania?