Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Dph's notes

  • Ok, I'm on break between my fall semester and spring semester of college and I will be so for a couple of weeks.  I ended up with a B in vb.net 1.

    That gives me time to finish up some goals:

    1)get Jesse v.02 ready to compile for distribution
    2)get James v.01 ready to compile for disribution

    What's the heck Jesse v.02 and James v.01?

    James v.01 is an application for saving data about map tiles for Gladiator into a binary file.

    Jesse v.02 will use data files created by James v.01 to edit maps for the games of gladiator.

    How far long am I?

    I finally started to code James v.01 to get the data entry to work (moving it beyond just being a static gui).  All I have to do is work out a file save format and I should be able to finish coding James v.01 rather quickly.

    What's the status of Jesse v.02?

    Obviously, it can't read the data files created by James v.01 since they don't exist.  I gotta code both the Insert Row/Column feature and the Delete Row/Column feature for maps and that's where I'm stopping on new features.  I, also, am going to try to put the thumbnail map features from Jesse v.01 into Jesse v.02.  Obviously, from my pov at least, I can't put the thumbnail features from Jesse v.01 into Jesse v.02 until AFTER James v.01 is finished AND Jesse v.02 reads the data files created by James v.01.

    Is there any other stuff for gladiator that I'm thinking of working on?

    Ummmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.  Yes.  It's contigent upon how hard it is/will be to get James v.01 to work like I want it.

    Tell me more.

    Ok, since you wanted to know.  When I started working on James v.01 again, It occured to me the similarities between the data files that James v.01 will create and the fss files used to store the data about scenario files.  I *might* be able to write a program to view the objects in a scenario file like you view records in a table in a database.  Such a program is on the list of items potentially to be put on my backburner.

    What aren't you telling us?

    D'uh, my time is limited.  I plan on attending a convention during the summer called "The Gathering of the Gargoyles" - http://www.gatheringofthegargoyles.com/ .  It's an annual convention for those who love gargoyles the tv series.  I'm paying for my way there as a present for myself for graduating college.  I started to work on a gargoyles card modelled after yugioh except the cards reflect things from the universe of the gargoyles.  As soon as I finish work on James v.01 and Jesse v.02, I plan on moving work on that card game from my back burner to my front burner.  My goal is to have the game ready by the convention.  I have a yahoo group for working on it - http://groups.yahoo.com/group/garg-card-game/ - but that's nothing for you guys to worry about.  I only mention it to explain why I plan on stopping where I plan on stopping work on gladiator related programs.

    D'uh, I will be putting my source code at snowstorm's sourceforge webiste.

    • I'm doing the data entry on James.  Here's the format of the flat file for info on map tiles:

      1 byte - version number of the file
      2 bytes string length descriptor - 16 bit (as opposed to 32 or 64 bit) integer
      string folder name - name of the folder where the graphic files are located
      2 bytes - 16 bit integer - height of the images
      2 bytes - 16 bit integer - width of the images
      2 bytes - 16 bit integer - number of tiles
      the rest of it is wirtten out as a single array of  type described below consisting of the number of tiles specified
      2 bytes - i6 bit integer - Tile Number
      string - name of the graphic file minus the extension
      string - internal name of the tile
      string - smoother type of this tile
      1 byte - 1 bit variable describing the amount of red to use to make the radar color
      1 byte - 1 bit variable describing the amount of blue to use to make the radar color
      1 byte - 1 bit variable describing the amount of green to use to make the radar color
      1 byte - 1 bit variable describing the amount of alpha to use to make the radar color
      1 byte - 1 bit variable indicating the value of its passable status

      If you guys can read that, we're in shape.

      I'm quite unhappy with the number of smoother type "TYPE_UNKNOWN" (2) that I've run into so far just doing the data entry for the 1st 9 tiles.  I'm thinking about creating some new smoother types when I get through just to cut down on the number of tiles that have a smoother type of "TYPE_UNKNOWN" .  Against my better judgement, I tempted to create a file listing the the all the smoother types and directiosn for how they relate to each other, something along the lines of if smoother type A is next to smoother type B, is that accpetable and if not, what smoother type needs to be next to it.  That way I can avoid hard-coding most of the smoother function, basically where all it needs is a row number and column number to determine if the tiles next to each other can stay next to each other.  I'm getting ready to enter the data for the 1st batch of carpet tiles into my file. 

      9 down, 125 to go.