[WIP] Archon II - Adept

[Ivan]

I have also come across an issue with the two separate images moving a very different speeds, even while set to the same initial speed. The 'order' piece on the left moves much slower than the chaos piece. It doesn't matter which one I start to move first, it's always the same result.

Hi I looked at the code and testing it on the battle board I think I have found the bug.
Looks like the same 'piece' gets parented by several containers. Here's the problematic code:

Code: Select all

         if currentType == self.FIRE then
            tile = self:getTile("Fire");            
         elseif  currentType == self.AIR then
            tile = self:getTile("Air");
         elseif  currentType == self.WATER then
            tile = self:getTile("Water");
         elseif  currentType == self.EARTH then
            tile = self:getTile("Earth");   
         elseif  currentType == self.ORDER then
            self.gamePieceOrder = GamePiece ( self.gamePieceOrder.imgPath, self.gamePieceOrder.imgFile, self.cellWidth / 2, i, j, self.gamePieceOrder.side )
            piece = self.gamePieceOrder
         elseif  currentType == self.CHAOS then
            self.gamePieceChaos = GamePiece ( self.gamePieceChaos.imgPath, self.gamePieceChaos.imgFile, self.cellWidth / 2, i, j, self.gamePieceChaos.side )
            piece = self.gamePieceChaos
         end
         
         if piece then
            self:add_child( piece )
         end

Basically, the piece object gets added as a child to a number of other containers.
Therefore, each of those parent containers calls "redraw" in the child piece thus moving both pieces at arbitrary speed.
Make sure you insesrt the following line at the beginning of the block of code above:

Code: Select all

         local piece = nil

There really should be an assertion to prevent this in the GUI module. Funny enough, I added such an assertion a couple of weeks ago in the latest non-public versions (not out on BitBucket yet). So, it might be a good idea to add the assertion by modifying a couple of functions in ContainerG (extensions/lua/gui/container.lua):

Code: Select all

ContainerG.add_child = function(self, child)
  assert(child, "Child node is nil")
  table.insert(self.objects, child)
  assert(child.parent == nil, "Child already parented by another container")
  child.parent = self
  self.node:add_child(child.node)
end

ContainerG.remove_child = function(self, child)
  assert(child, "Child node is nil")
  if self.focus == child then
    self.focus = nil
    self.exclusive = false
  end
  if self.hover == child then
    self.hover = nil
  end
  local i = self:get_child(child)
  assert(i, "Child node is not parented by this container")
  base.table.remove(self.objects, i)
  self.node:remove_child(child.node)
  child.parent = nil
end

Once you get that settled, you may notice that both pieces are moving at a much slower speed.
This is actually the 'correct' behavior since you have the speed set to 1 which means 1px per second.

Also, I should mention again that when a key is held down for over half a second, "key_command" gets called every 5 ms (in practice it's more like every 16 ms).
This is not a problem given your code (since you're not actually moving the pieces during "key_command") but I'm just reminding you that the function is called repeatedly while "repeated keystrokes" are on.

Not sure what might be causing the font issue. Maybe Phil will have something to say since he actually works on the engine itself. What's your videocard by the way?

[hardwarebob]

Hi Ivan,

I have fixed the bug you have found, and yes, they now move at the same speed.

I have also added the changes to your gui.lua

It is working nicely now and I have also been able to start implementing firing projectiles from one of the players. It also handles collision with the enemy piece and the edge of the gameboard, although I'm sure these could be improved somewhat, at least its a good start.

As for the graphics card, I'm using an integrated card on the laptop. The manual displays the following details for this:

I'm not sure if the integrated card is the NVidia, or if it's an optional card which is not in the laptop. It is definitely not a separate card though.
Intel HM55 Intergrated
nvidia N11M-GE1 with 512M DDR3 VRAM

[Ivan]

Hi. I tried the latest version and it seems to be working.
Haven't played Archon, but I assume that the battle screen is going to have real-time action?
Can't say for sure what the issue with the fonts is, but your video card looks recent enough.
The font rendering issue might be caused by Windows 7.

Also, I should mention that I've put up an update to the GUI on Bitbucket, but I wouldn't advise applying it to your code right away since you'll have to make modification.
Basically I've added a new object type called "vcontainer" which is a clipped container using viewport.
The major benefit is that you can assign a camera to vcontainer and render a separate "scene" within the GUI system.
I needed vcontainer for two prototypes that I was working on (a Box2D game and a TBS).
As a result, my game logic became much less "coupled" to the GUI framework - basically vcontainer serves a "viewer" class.
The downside to this is that several things had to be changed:
-the default origin point (0, 0) is now the upper-left corner of the window with the Y-axis pointing South
-the default viewport is overlapped (including the agen terminal but there's a workaround)
The other major change is:
-"redraw" is no longer called automatically for objects
-instead of "redraw" each object gets a call to "update(delta)". This way objects can decide to do a full/partial redraw only when their contents/dimensions have changed.

PS.Regarding the fonts issue, can you please test if they are rendered incorrectly using the OpenGL plugin?
You can select the OpenGL plugin from "settings.ini":

Code: Select all

[video]
plugin=Plugins\AgenDX8.dll

Simply change the above line to:

Code: Select all

[video]
plugin=Plugins\AgenOGL.dll

[hardwarebob]

Hi Ivan,

Haven't played Archon, but I assume that the battle screen is going to have real-time action?

Yes! The GameBoard is more like your 'strategic' area, where the aim is to manoeuvre around the board and ultimately gain more power in order to defeat your opponent.

When two pieces occupy the same space, the battle between those two pieces begins.

I have this working with the two 'A1' pieces, where if you select one and place it on the other 'A1' piece, the battleboard is displayed with those pieces.
When one player is reduced to zero or less health the battleboard is supposed to disappear and the GameBoard will reappear.

At the moment I have the battleboard disappearing, but cannot get the GameBoard redrawn, it's just blank.

Assistance with this part would be great! Please note that I have merged my previous branch on bitbucket back to the default one.

Logic to assist investigation:
1. GameBoardG.syncSelectionBuffer
This checks for two enemy pieces in the same location and creates the battleboard
2. BattleBoardG.finishBattle
Called when a player reaches zero health
3. GameBoardG.battleFinished
Supposed to re-add the surviving gamePiece back on the gameBoard and redraw it.

PS.Regarding the fonts issue, can you please test if they are rendered incorrectly using the OpenGL plugin?

Tried this, still the same.

I also tried to run Agen on my Windows XP virtual machine, but it has an issue finding the video card and crashes on loading any Agen code.

I will also see how it runs on my PC (Windows 7) and let you know.
Both my systems are x64 as well, in case this makes a difference.

Your new code sounds interesting, but yes, I think I will stick with the same GUI for now, otherwise I will forever be re-writing my code!
After the game has progressed much further, I may revisit your most recent version and go from there, but I am definitely glad I dropped your old GUI, as your new one is so much simpler to work with (good job! )

[Ivan]

Hi. I tried the latest code you had on BitBucket and noticed that there was a failed assertion in the GUI (your GUI code might be different so you may have missed it):

Code: Select all

         local tile = nil
         local pieceOrder = nil
         local piece = nil
         
         if currentType == self.FIRE then
            tile = self:getTile("Fire");            
         elseif  currentType == self.AIR then
            tile = self:getTile("Air");
         elseif  currentType == self.WATER then
            tile = self:getTile("Water");
         elseif  currentType == self.EARTH then
            tile = self:getTile("Earth");   
         elseif  currentType == self.ORDER then
            piece = self.gamePieceOrder
         elseif  currentType == self.CHAOS then
            piece = self.gamePieceChaos
         end
         
         if piece then
            piece:updatePosition( i, j )
            self:add_child( piece )
         end

Looks like "piece" is already parented by another container (probably the Game board).
Therfore, when you call "self:add_child", the child node isn't removed from its old container (as it should).
This could result in the piece being parented by 2 containers.
The simplest solution (implemented in the new GUI) is to just remove the child from its previous container whenever a call to "add_child" is made.
I suggest changing the following 2 functions in "container.lua" so that you can avoid strange bugs:

Code: Select all

ContainerG.add_child = function(self, child)
  assert(child, "Child node is nil")
  table.insert(self.objects, child)
  -- remove child from previous container
  if child.parent then
    child.parent:remove_child(child)
  end
  child.parent = self
  self.node:add_child(child.node)
end

ContainerG.remove_child = function(self, child)
  assert(child, "Child node is nil")
  if self.focus == child then
    self.focus = nil
    self.exclusive = false
  end
  if self.hover == child then
    self.hover = nil
  end
  local i = self:get_child(child)
  assert(i, "Child node is not parented by this container")
  child.parent = nil
  base.table.remove(self.objects, i)
  self.node:remove_child(child.node)
end

At the moment I have the battleboard disappearing, but cannot get the GameBoard redrawn, it's just blank.

This is actually kind of a funny bug. See the last line here:

Code: Select all

     -- todo: check if sBuffer[1] is an enemy piece, if so display new battle board
     if self.isEnemyPieceSelected ( source, dest ) then
      self.node.visible = false

The game board is still there we just can't see it. We have to make it visible once the battle is over:

Code: Select all

GameBoardG.battleFinished = function ( self, p1Piece, p2Piece )   
   self.node.visible = true

Hope this helps.

[hardwarebob]

The latest version now uses 'main.lua' instead of 'gui_demo.lua' for the initialising class, so change any batch file you have.

Looks like "piece" is already parented by another container (probably the Game board).
Therfore, when you call "self:add_child", the child node isn't removed from its old container (as it should).

Yes, not sure which version of the code you had, but I am already removing the gamePieces from the game board before creating the battle board inside the 'GameBoardG.syncSelectionBuffer' function. When I insert your updates, I will remove this clean up code of mine.

The game board is still there we just can't see it. We have to make it visible once the battle is over:

Yes a very obvious one, I completely forgot I had set the visibility property for that! It's now working nicely, thanks. This is what happens when I work on this late at night after work!

Coming along nicely again, I now have the winning piece placed back on the game board after the battle, the loser being left out.

I'm now up to doing some more work on the game board area and enabling the players to summon spells (including other game piece types). As all of the GUI plumbing is now in place, it's so easy to add these extra bits for the game (yes, more kudos to you for your hard work on getting the gui to where it is )

[hardwarebob]

Hi Ivan,

I have managed to fix that strange font display issue when using your 'label' object.

It turned out to only display oddly when the calculations for the center align were not a whole number.
I have a put a quick fix in your code by just rounding down, as shown in the snippet below and the issue never appears.

Code: Select all

if self.styles.align == 'center' then
    x = self.width/2 - w/2
   x = math.floor(x)
  elseif self.styles.align == 'right' then
    x = self.width - w
  end


[Ivan]

Hey, nice to see that you've pinpointed the bug. Looks like it might be caused by the font rendering in Windows 7 since on XP the fonts look normal. Your solution should work fine in most cases. One thing to note is that even if you use integer coords when 'writing' on a canvas, the text may still be rendered at a floating-point position if it's sprite ('node' in this case) is moved by say, half a pixel. This really needs to be fixed on the engine side.
Other than that, I tried the latest version you have on BitBucket and it looks good. Keep it up man, seems like most of the UI-related stuff is nearly finished. At this rate, you'd be finished pretty soon.

[hardwarebob]

Hey there Ivan, thanks for the positive feedback!

seems like most of the UI-related stuff is nearly finished

Yes, it is pretty close.

At this rate, you'd be finished pretty soon

Yes, the two player mode for it might be done in a month or so, as I don't get much time to work on it.

After that, my next challenges would be AI for single player and then networking support.

I have another part where I am a bit stuck.

I have implemented some code inside the GameBoard object, within the GameBoardG.mouse_event function for highlighting valid cells for moving a selected gamepiece.

On line 289 I have the following comment block:

Code: Select all

--[[
   THIS HAS BEEN COMMENTED OUT TO TRY AND CALL FROM GAME.LUA INSTEAD
   -- get array of valid moves and display on board
   self.validCells = self:getValidMoves( selectedPiece1.cell:getNeighbors(), self.mCells[j][i], selectedPiece1.name )               
   self:setMovementPath( self.validCells )
   ]]

Now, I have been trying to implement this in the game object instead, making it more centralised, as it makes it easier to integrate the logic into other required areas.

The GameG.mouse_event doesn't seem to be called at all and I don't understand why. Since this is the parent of GameBoard, I thought it would be called first.
I can tell it is not called, as I have some logmessages in here that are never logged.

Now, I have already implemented the GameG.key_command function and this works fine. It is called on key events and it passes them on down to the GameBoard object as required. Again, I have some logmessages in here to verify this.

I imagine it is something to do with how the container mouse events are implemented in comparison to how container key events are.

[Ivan]

Hi. First off, I have to say, nice work - the code is a lot cleaner now.
This looks like bug in "game.lua" - you have 2 versions of "mouse_event" defined there, where the second one is:

Code: Select all

GameG.mouse_event = function(self, event, button, x, y)   
   local focus = self.focus
   -- pass down the event to the object in focus
   if focus then
      local lx, ly = focus:to_local(x, y)
      focus[event](focus, button, lx, ly)
   end
end

You have to delete that second version of "mouse_event" because it overwrites the first one.
If you need to use the default Container "mouse_event" function from the Game object you can call "ContainerG.mouse_event ( self, event, button, x, y )"
Once that second function is removed, you'll get a Lua error from:

Code: Select all

      if self.selectionBuffer[2] then
         --gameBoard:clearMovementPath( self.validCells )
      end
      
      gameBoard:setMovementPath( self.validCells )

Where self.validCells appears to be "nil", but this doesn't look like it would be too hard to fix.

PS. I'd also like to mention that the engine documentation is being updated periodically as well. The online version is usually most recent but if you don't have a constant internet connection you may want to get it from the last Windows build (7/10/2012). Just be careful not to overwrite your "Extensions/lua" folder with the new version of the GUI.