![\"unitpicking_1\"](\"https:\/\/www.kamremake.com\/devblog\/wp-content\/uploads\/2013\/07\/unitpicking_1.png\")
<\/a><\/p>\nThe blue quad shows the area you had to click in order to select pikeman that is standing on it. As you can see that area does not matches his body shape that well. If you clicked on his head the click would go to the empty tile above and nothing will get picked. The situation is even worse if you wanted to pick a walking unit. The place unit is located is rounded to a nearest tile. Notice how far archers flag carrier is from the place where you need to click to select him:<\/p>\n
Imagine players frustration clicking on a unit and getting nothing or another unit.\u00c2\u00a0Is there a way to solve this problem? Even in old KaM unit selection was pixel-perfect. We know it’s possible, but how?<\/p>\n Old KaM could do pixel-perfect picking because all the games sprites were in system memory. CPU had direct access to pixel data. That means the game could hit-test sprites that are drawn under the cursor right in the drawing cycle. Here’s the pseudo-code how it may have looked like:<\/p>\n However with KaM Remake that is not gonna work because we use OpenGL for render which operates with GPU and GPU memory. On games startup we load the sprites from the disk only to pass them to video memory, as soon as that’s done we flush them from system memory (that’s some 140mb saving). Afterwards sprite data is not directly accessible to the CPU. Of course we could try and read that back from video-memory, but this is quite slow operation since GPUs are made with directional data transfer in mind. Proper GPU approach is slightly different. Since drawing on GPU is practically free, we can employ so-called “color-picking” technique.<\/p>\n Color-picking is named so because we ask GPU to draw different objects with different colors to a “selection buffer” which is invisible to a player. We are going to render a bunch of sprites that are already in GPUs memory (which is practically free operation). Then we read just one pixel that is under the cursor and knowing its color we can easily detect to which of the rendered objects it belongs.<\/p>\n From talk to rendering – each active object has an unique ID in the game. We take that ID and encode it into RGB color. Here’s result:<\/p>\n As you can see there are some issue: Trees (that are rendered in black, because they have no IDs) occlude the soldiers. Opaque trees almost prevent player from picking soldiers behind them. This is not good for the player, because he will not be able to pick soldiers in woods. Serfs arms are rendered separately without an ID, they should inherit serfs ID. On the other hand units shadows should not be pickable.\u00c2\u00a0Each issue is easy to deal with by different techniques.\u00c2\u00a0After fixing these minor issue we have the following picture in our “selection buffer”:<\/p>\n How is it looking from the implementation point of view?<\/p>\n After normal frame is rendered as usually to the back buffer and swapped to display we fill everything with black (black means no ID) and render objects sprites once again, but this time we don’t show it to the player. Only the game has access to the render result and read the pixel color under the mouse cursor.<\/p>\n First tricky part is to make OpenGL to render opaque texture pixels with a flat color we need. For that we use this clever bit of code found at StackOverflow:<\/p>\n For each sprite we set up a color that will represent its ID. Typical OpenGL render offers 24 bits for RGB values. We can split the ID into bytes and code this like so:<\/p>\n We also discard any inactive objects (trees and flags mostly). Here’s what we get in the selection buffer in the end:<\/p>\n Now we can read the pixel under the cursor with a glReadPixels procedure and combine its RGB values back into an ID. That ID belongs to a unit that is standing there.<\/p>\n That’s it. Now you know another improvement that will be in the next KaM Remake version. Thanks for reading! \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" In this article I’ll try to explain how the object picking works in KaM Remake, why is it worse than in classic KaM and how it is going to get better in next release. Proceed inside if you are interested … Continue reading <\/a><\/p>\nPixel-testing (vanilla KaM approach)<\/h2>\n
\/\/Render all visible sprites\r\nfor i := 0 to VisibleSpriteCount - 1 do\r\nbegin\r\n \/\/Render the sprite\r\n RenderSprite(Sprite[I]);\r\n\r\n \/\/Fast test if cursor is within sprites rectangle\r\n if InRect(Cursor, Sprite[I].Rect) then\r\n begin\r\n \/\/Get exact cursor position within sprites rectangle\r\n PX := Cursor.X - Sprite[I].X;\r\n PY := Cursor.Y - Sprite[I].Y;\r\n\r\n \/\/Check if there's opaque pixel in that position\r\n if Sprite[I].Pixels[PX,PY] <> 0 then\r\n \/\/Remember picked sprite\r\n Cursor.Object := Sprite[I].Object;\r\n\r\n \/\/If there's any sprite above it will get picked instead\r\n end;\r\nend;\r\n\r\n\/\/We don't have KaM source codes, so that's just an idea<\/pre>\n
Color-picking (new approach)<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\n\u00c2\u00a0Technical side<\/h2>\n
<\/a><\/p>\n\/\/Render textures without semi-transparency.\r\n\/\/Anything below 0.9 will be discarded (i.e. shadows)\r\nglEnable(GL_ALPHA_TEST);\r\nglAlphaFunc(GL_GREATER, 0.9);\r\n\r\n\/\/Texture will not be blended with background\r\nglBlendFunc(GL_ONE, GL_ZERO);\r\n\r\n\/\/Set up custom combining mode where texture color is ignored\r\nglTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);\r\nglTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_REPLACE);\r\nglTexEnvi(GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);\r\nglTexEnvi(GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE);\r\nglTexEnvi(GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);\r\nglTexEnvi(GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR);<\/pre>\n
\/\/SHR is bitwise shift to the right\r\nglColor3ub(ID and $FF,\u00c2\u00a0ID shr 8 and $FF,\u00c2\u00a0ID shr 16 and $FF);<\/pre>\n
<\/a><\/p>\n