Skip to content

Bitwise vs. Boolean

Jump to bottom
JakeSamiRulz edited this page Mar 17, 2015 · 1 revision

Google Code - Development Systems Document
Holds information regarding the save storage data of the map.

Introduction

Today, it is all about the Map. A map is a double array of tiles represented by integers and Objects. However, storage of huge maps increases the likelihood of memory loss, and handling great big maps is a timely process. So, it was time to take a break from Object Orientation and back into Machine coding. It is time to mess with bits.

The Breakdown

Tiles were my first targets for optimization. In order for me to take full advantage of them, they had to be broken down to a solid base. I ended up doing a few things to make sure that I am maximizing the potential of the bytes without losing too much information so we can’t display the items on the screen.

Tiles are made up of 2 major things. Display of Terrain/Properties, and display of Units. In this program, Units are treated separately from Terrain, so therefore, the data will also be separated into Terrain (Fields + Properties) & Units.

Terrain Data will be treated in a double array list which will keep track of the byte values.
Unit Data will be treated in a single array or hash which will keep track of byte values.

Saving Space

The game carries a big load of being expandable/customizable for both units and terrain, there is a huge chance that one version will not carry another versions units and terrain. In order to help compensate for this, I am implementing index names made up of 4 character values e.g. [INFT] to help define a separation between each type of unit/terrain/property. I am really going to stress that each ID is unique from one another. Otherwise, the first one found will be loaded.

The Split

The purpose of using distinct ID’s for the items allows me to define the items as indexes. Below is a example of an index.

  • 0:INFT:INFT
  • 1:MECH:INFT

<Index Number (byte)> <Type (4 char)> <Base (4 char)>

Index Number

Index numbers are used to define what bytes mean in the map items. The advantage of having the index numbers in a loose manner is that the map will not have to store every single object within them, but instead they’ll only store the objects that they are using within the maps. This makes inclusion of customized items easier to manage, because the program will not have a solid set of integers representing a map. Instead, it’ll generate the integers on the fly for each map (dynamic binding).

Type

The only thing that’ll make this system work is defining the type of object (unit, terrain, or building) that is in the map. Each object will have a distinct 4 letter type composed of characters. The program will then look up the type to decide if the object is available within the clients program. If not, we can either poll the user that the unit type is not available… or use the base.

Base

The base is a backup type. Instead of units not being drawn to the screen when not available; the backup type will put replacement units of the type you specify here in their place. This system is there to make sure that the map will always attempt to display something, even when the units/ inventions aren’t available for play.

If the Base backup isn’t available… the map will fall back to just Plains for terrain/buildings, and will not create the unit.

Proposed Type Definitions

Unit

  • (INFT) Infantry
  • (MECH) Mech
  • (BIKE) Bike
  • (SNIP) Sniper
  • (RECN) Recon
  • (AAIR) Anti-Air
  • (APCR) APC/Rig
  • (TANK) Tank
  • (MDTK) Medium Tank
  • (NTNK) (Neo) Battle Tank
  • (WRTK) (Mega) War Tank
  • (SPTK) Spider Tank
  • (BCRT) Battlecraft
  • (OOZM) Oozium
  • (FLRE) Flare
  • (ARTY) Artillery
  • (RCKT) Rockets
  • (MISS) Missiles
  • (PRNR) Piperunner
  • (ATNK) Anti-Tank
  • (ACRT) Artillery-Craft
  • (TCTR) Transport Copter
  • (BCTR) Battle Copter
  • (FGTR) Jet Fighter
  • (BMBR) Bomber
  • (BKBM) Nuke (Black Bomb)
  • (STLH) Stealth
  • (SEAP) Seaplane
  • (DUST) Duster
  • (ZPLN) Zeppelin
  • (SPYP) Spyplane
  • (HCTR) Heavy Copter
  • (BSHP) Battleship
  • (CRUS) Cruiser
  • (SUBM) Submarine
  • (LNDR) Lander
  • (BKBT) Black (Patrol) Boat
  • (ACAR) Aircraft Carrier
  • (GNBT) Gunboat
  • (DSYR) Destroyer
  • (SRNR) Shuttlerunner (Obsolete)

Terrain

  • (PLIN) Plain
  • (FRST) Forest
  • (MNTN) Mountain
  • (RIVR) River
  • (ROAD) Road
  • (BRDG) Bridge
  • (REEF) Reef
  • (WTLD) Wasteland (High Grass)
  • (RUIN) Ruins
  • (SHOA) Shoal (Beach)
  • (SEAS) Sea
  • (METR) Meteor
  • (PLZM) Plasma
  • (PLZP) Plasma Pipe
  • (PZPS) Plasma Pipe Seam
  • (PIPE) Pipe
  • (PIPS) Pipe Seam
  • (PIPR) Pipe Rail
  • (SWMP) Swamp
  • (MIST) Mist
  • (RSEA) Rough Sea
  • (FIRE) Fire
  • (NULL) Null Terrain

Properties

  • (HEAD) Headquarters
  • (CITY) City
  • (BASE) Factory/Base
  • (APRT) Airport
  • (SPRT) Seaport
  • (CMTR) Communication Tower
  • (SILO) Missile Silo
  • (RDAR) Radar
  • (TAPT) Temporary Airport
  • (TSPT) Temporary Seaport
  • (STRH) Stronghold
  • (LABS) Lab
  • (QURY) Query
  • (ORIG) Oil Rig
  • (WALL) Wall

Advantages

  • Working maps: There is no such thing as a non-working map in CWT, as the map will always try to at least draw something to fill up the spaces.
  • No Object Accountability: By sticking close to the types, maps that work for one modification will work for many regardless of the object types chosen for that map. Objects are never forced into a modification, so there is no need to account for every object when building a game.
  • Map Loading portability: This system will make it a lot easier to convert foreign map types to be readable by CWT. Map templates can easily be inputted into the system via hardcoding or XML template.

Disadvantages

  • Overhead: Without predefined hard coded indexes, they’ll have to be generated in-game. Time taken to generate a map will take a bit longer due to this.
  • Bigger Map files: Storing the types and backups will take a lot more space, if there are a lot of individual objects. However, the size of the internal map storage will be a lot smaller. All-in-all… maps will benefit if they don’t carry plenty of distinct objects.
  • Limit: The total number of distinct objects for any given type (Units, Terrain, and Buildings) in a given map is 256 for each type. This limit is imposed to improve index speed for maps, but it can be broken by people who want to include over 256 different types of unit in a map.

Storage

I will not go into too much detail of map storage. But this bit system will help comprise the storage of maps within the game.

Optimization

According to research, Boolean is slower than native bits by about 50%

Bitwise Help - Vipan

Therefore, native bits will be used for referencing rather than counting on BitSet Booleans. This will ensure the fastest speeds for doing the byte conversions for the Map.

Clone this wiki locally