Yes,

That's possible.
 
I can transfer the texture from the texturebuffer to the imagebuffer.
(I can't save textures, but I can save images.)

From there I can save the contents of the imagebuffer in
the form of a normal bitmap to the hard drive.

(Is your idea perhaps to generate lightmaps for all indoor-scenes
at the start of a NEW game (for one time only) ? )
   

Thanks Elvenfyre & Ty

It may seem that development is a bit slow, but I can
assure you that everything is going well.
All code is written with the long term in mind.

The town is "populated" with a large number of different models.
Each of these models has a separate LOAD-&-SAVE file. That means
that everything is also coded separately. Ok, it's a lot of
work short-term, but it's getting easier on the long-term.

-#-

More news on the development front:

I got the Portable-LightMapper (= PLM) working.
It's great for small indoor-scenes.
Especially for the interior of a house. On the other hand, the prison I'm working
on, is enormous. In fact, it is so big , that I had to split it up into three separate levels.
Even if I use the PLM for each of these levels then it will take too long to make a lightmap.

These are results of the latest tests:
--------------------------------------
Time passed during test with loading B3D-file
of Prison level 1 with pre-generated lightmap: 2.556 seconds

Time passed during test with loading B3D-file
of Prison level 1 with "on-the-fly" generated lightmap: 13.491 seconds

... I rest my case...

Therefore, I've decided to use the PLM for small levels and pre-generated lightmaps
for large levels. There's also one thing I forgot to take into account:   :/ 

When you put all the media into one ZIP-file, the overall filesize is going down.

A note on lightmaps: In CarthographyShop & Maplet it is possible to choose the size of the lightmap. 

Below are some testresults on mapsize with high mapdetail and 16x oversampling:

- 256 x 256 px   : 192 Kb unzipped /  32 Kb zipped
- 512 x 512 px   : 769 Kb unzipped / 113 Kb zipped 
- 1024 x 1024 px :   3 MB unzipped / 133 Kb zipped 

Phew, that's enough ranting from me

See ya soon

Hi Peeps,

A small update on how things are progressing.

I've been coding like mad at the level-up code.
How many experience-points does a character receive when killing a monster?
How many points does he/she have right now and how many points until level-up ?

I lost the plot a bit at how the game handles promotion.
Reading the SFII boards on Shining Force Central, I've noticed that there are basically two camps of players.
One camp does its promotion-ceremony as quickly as possible (lv. 20) , while the other camp
waits until lv 40.

On Gamefaqs (yes, a lot of research-time was spent on this problem. )
I've found a FAQ from Apathetic Aardvark ( )   
( http://www.gamefaqs.com/console/genesis/file/563341/28017 )
He stated that the original SFII-program treats the promotion at level 20.

So, I think that means: even if I leveled up a character to level 35 (NOT promoted), then promote him/her,
the game will set its level back to level 1 (promoted) . So that makes it level 21 , right ?

The characters that "practice" magic might now have the following problem:
At some levels they either get a new spell , or gain a level for that spell.

For example:

Sarah learns HEAL 3 at Level 33.
That means: level 33 unpromoted OR level 13 promoted 

or.....

level 33 unpromoted AND level 13 promoted ?

o_0

Is there someone that can explain this a bit more clearly ?

If the latter is the case, then I think I need an extra flag for checking whether a character
has received a new spell / spell-level.

-#-

The AI is coming slow at the mo.
A character keeps filling the grid-sections with his ID-number when moving around.
So , when the next enemy checks if a character is near  , he stops at the first grid-section he comes across,
even when there is nobody around o_0. I have to suss this one out before I continue.

-#-

I've also learned a few things here and there about animation for characters,
and bought a few books with examples on how to draw heads , eyes , bodies.
A list which contains info about animation-sequences for each character,
(walk , jump , attack , defend , special attack , etc. ) eye-expression (if applicable), fighting stance and
spell-casting stance is in the works. This could be a [very ]long list.    

Nice reference on animation: http://www.youtube.com/watch?v=UqENARuEGM0


See ya

Hi all,

Last time I promised a bucketload of screenies....well... here are at least two (it's a small bucket j/k )

Anyway,



Here is an update on how the town 'gets more busy'.
In the distance you see the church and there's also a fountain. The town is surrounded by mountains.
I've moved the mountains a bit further away [not pictured here], so it feels less 'cramped'.

The skybox is now in place. A skybox is just a cube, flipped inside out.
It's drawn first , so it's behind everything else.
It's also parented to the camera. So, when the character moves , the camera moves.
Ergo, it's impossible to walk towards the edges of a skybox.         
I have a couple of texture-sets that fit perfectly on a skybox.

There are also textures that look better when placed on a sphere. 
These textures take a fair time to load (they're quite large), and texturing the sphere with them
also takes its toll on performance. Luckily, that last part is becoming a non-issue.

The idea is to load these images as a brush instead of a texture.
Working with brushes [by painting entities]is much faster than texturing entities.
Next, load one skyBOX and one skySPHERE. Flip the meshes , and set their entityorder.

Now , when entering a map, a copy is being made from the original skyBOX or skySPHERE.
The appropriate brush is now applied to this copy. Very simple ..and very fast too

So far, everything you see in this picture , is loaded in less than 2 seconds.
The same is true when moving from one map to another.

ahem... the next picture(s)





This is the final model for the inside of the church.
It is the same model but I've applied a different lightingstructure to it.

The top picture has the lightsources placed between the walls and each column in high resolution.
The bottom picture has the lightsources placed on the OTHER side of the columns in medium resolution.

I hope you can spot the difference

So.,... the model is finished, but I have something else in mind. You see, in SFIII there isn't much lighting.
Well, there are a few shadows here and there, but that's about it. And I really want a bit of lighting for every
indoor scene.

The problem is: every [indoor] map has its own lightmap. This lightmap is just a bitmap with light/dark patches
for every surface in the model. 50 maps .... 50 lightmaps, etc etc.
All these extra bitmaps make the entire game quite big.

There are models, textures, sprites , images , sounds , music, heightmaps, datafiles and other assorted fluff.

As luck would have it , someone made a "portable lightmapper" in Blitz.
Now, if I can get this code to work for Dark Resurrection then I would be a very happy person indeed.
A lightmap could then be made "on the fly" with no extra media.

More coding news in my other thread.

See Ya

Thanks 

Of course I would like to help.
Just tell me what type of advice you need...( AI , programming in general , camera-code , etc)

Also, I take it that you are dutch too?

Yup, 100% Cheesehead

If you need tips in Dutch ,  then that's okay too (mail me at: sodalee AT dso DOT denhaag DOT .nl )
 



   

Everything is going well with Dark Res. I've made 4 more houses each with a different texture-set.
Total number of different houses is now six . There are also six different textures, so that makes 36 different versions.
That should be enough , don't you think ?

Anyway, I've programmed the code for the entrypoints.
These entrypoints are important for changing maps , and for deciding where to position the player-character.
Each entrypoint contains information about the map you are currently ON, and the map you are going TO.
That means , when you are near one of these entrypoints, the program changes maps.
Each map has a unique number.
Each object that can be entered (house,depot,shop,church,castle,HQ,worldmap,areamap) also has a unique number.

Example:
You enter a townmap from direction of the map of the harbour. This map [of the harbour] is numbered "5"
You are standing in the middle of a town. The map of this town is numbered "1".
You walk down the street and would like to enter a house with two floors. This house is numbered "2".
Now..., you are entering the detection range of the entrypoint in front of that house.
The entrypoint decides that it is time to switch maps. 
The map-info of this entrypoint is as follows: Current_Map = 1 , Next_Map = 2

Before the switch: MAIN_MAP = 1               , PREVIOUS_MAP = 5
During the switch: PREVIOUS_MAP = Current_Map , MAIN_MAP = Next_Map
After the switch:  PREVIOUS_MAP = 1           , MAIN_MAP = 2

You are now inside the house, and because this is a house with two floors,
there are 2 ways you could enter this particular map, 1) from the outside and 2) from the first floor.

As luck would have it, ( ) you've entered the ground floor via the outside map,
so that means - based on the values in the variable PREVIOUS-MAP - your playercharacter is positioned
near the front door, otherwise it is positioned near the stairs leading to the first floor.

And another problem rears its ugly head....

What to do with all those models ? Sure , I can use CLEARWORLD() , but that would delete everything
from memory, including entities , brushes and textures.
And to load everything again, each time you enter a new map is frankly.... ridiculous.
Therefore I present to you: DELETEWORLD()

What DELETEWORLD() basically does, is going through each type (and there are types for everything
you can think of) and free the model in that type along with the handle of the type.
If a copied entity is freed from memory, all the children that spawned from the parent, are automatically freed too.

Also, when you start the program everything (except the level-maps) is loaded once.
During program-execution all following models are just copies of the loaded entities.
According to other experienced Blitz-users, COPYENTITY is much faster than LOADMESH or LOADANIMMESH.
When program-execution is fast, then there is practically no waiting time for the user.

That's what it's all about.

-#-

I really really really.... REALLY want to show you some new piccies.  It's just that all my time is used for programming, modelling etc. I could make a small movie , to show everything at once. 

Whoops, I almost forgot ....
All the animated icons (itemshop,weaponshop,depot,church,walkabout) are IN.
Yes, yes...... everything is working beautifully    , and there's even less code compared  to the first version.

A long time ago , in a galaxy far, far away... (oh wait, that's another story..   )
But a long time ago nonetheless, I lost one of my USB-sticks.
It contained code for displaying the icons. And it was also one of those rare
occasions that I did not make a backup copy.   
I guess that sometimes, something good can happen out of a bad situation 

's good.

Well, think I'll shut up for now ...

See Ya's  


 
   

More progress on the scripting-front:

The AI is split up in SCRIPTS and TASKS

So far I have 10 different SCRIPTS, including "building units in order to occupy a neutral base",
"harassing the player" , "fortifying main base" , and a few other "surprises"

Each SCRIPT has a PRIORITY-number and a pre-determined number of TASKS.
PRIORITY ranges from 1 to 10 , with 1 being the highest priority and 10 the lowest priority.

Some SCRIPTS are activated by an AI-helper function.
This function issues a number of SCRIPTS based on GAMETIME.
Other SCRIPTS are activated on EMERGENCY , including : "low on energy",
"player attacks main base" , "player has more bases than AI".

Like I said , each script has a number of tasks.
Every task has its own ID-number and another number which basically is the same ID-number of the script it belongs to.
Each script also has a counter. This counter holds the number of the task that is currently running.

If a task is finished, then the counter points to [the ID-number of] the next task on the list.
A script is deleted when its tasks are finished.

"Why use a system of scripts and tasks ?"
I did it this way because it's possible to abandon a script that is currently running,
and to start another script with a higher PRIORITY.

Each time a script is added to the list, all scripts are (re-)shuffled according to their PRIORITY,
and the avatar only executes the first script it comes across.

So, when a script is deleted, the next one on the list could very well be the abandoned one I told you about.
Each script can only exist once , when its on the list. It's therefore possible that the AI-helper function wants
to activate a certain script which is already running.
In this case, the script is set aside as long as the previous one is running.

And now the tasks:

These range from "build a certain unit with a certain order" , "check a location" , "replenish avatar" ,
"replenish unit" to "attack player" , "move to main base" and "move to nearest friendly keep"

I'm trying to write AI that doesn't cheat , because that wouldn't be fair. ( "O rly ?")

It is possible that the first time you get trashed by the computer on later missions,
because , let's face it, the AI always knows exactly what to do (to a certain degree).   

Elvenfyre has written very good story-material, but I'm not explaining the story here,
because that would ruin the surprise(s). 


Aaaand,

For those of you , who follow the progress of Dark Resurrection: I've written a new post about its progress.

Stay tuned peeps.

There's also quite a few hits for "Dark Furniture", which you can blame on Peter (for this post).

*sound of demonic cackle*


LOL 

Here's an update on how things are progressing:

-#-

New: the BUY screen is working. On this screen you can see the:
1- ordername
2- ordercost
3- unitname
4- unitcost
5- total cost (combined cost of order & unit)
6- total units

Using the UP/DOWN cursorkey switches between Order / Unit / Radar Type
Using the LEFT/RIGHT cursorkey switches between each Order / Unit / Radar Type
SPACE confirms the current selection of UNIT & ORDER
ALT brings up / cancels the BUY screen

While the computer is "building" the unit, you will see an animated icon that represents the construction.
I've chosen the REPAIR-ICON from SFII, which ,I think, perfectly represents the "hammering away".

When the unit is ready to be picked up, the building icon is removed,
and in its location is now the "YES-nodding" icon from SFII. This animated icon will continue to blink
to remind the player that a unit can be picked up.

While pressing SPACE and hovering over the main base OR a friendly keep, will instruct your avatar to pick up the
requested unit. Avatar goes into CARRY-mode. 

Pressing SPACE while in CARRY-mode will release the carried unit onto the ground.
(of course you can only place land_based_units on land & sea_based_units in the sea )

Pressing SPACE while in FLY-mode and NOT hovering over one of your units will instruct your avatar to go into WALK-Mode 

Pressing SPACE while in WALK-mode returns your Avatar back to FLY-mode 

Pressing ALT while in CARRY-mode will bring up the GET-NOW screen. On this screen you see what unit you've picked up along

with its current health , HP , MP , etc. Toggle between the LEFT\RIGHT cursorkeys to change the order.
Press SPACE to confirm & press ALT again to cancel the GET-NOW screen.

Just to be on the safe side: I'll program some sort of switch that makes sure you pay only for a new order -ONCE-
if this is different from your previous order.

-#-

New: It is now possible to play in FULL SCREEN / SPLIT SCREEN - VERTICAL / SPLIT SCREEN HORIZONTAL

-#-

New: You can control your avatar with the cursor keys. Left\Right turns & banks your avatar in that direction.
UP accelerates , DOWN brakes(!)

Also thinking about manual key configuration and maybe use of a joypad would go down well too.
(including joypad (RE-)configuration). 

Right now I'm tinkering away at what the ideal size should be for the grid (used for A-star AI).
Currently looking at 10 units for each grid-square with a total terrainsize of 1024 x 1024 units.

-#-

New: Tower unit is finished

-#-

Working on the Merman-unit. It's nearly finished, just needs a trident    

I'll make a separate post about AI, otherwise this post will be very boring (Yawn)

See Ya    
     

The player can only "order " one unit at a time.

-#-

I've been playing around with the counters that represent the time that is needed
to construct a certain unit.
I've come to the conclusion that more expensive units take more time to build them.

*kicks in open door*



I'm working on a list with units and their construction time. Starting with the infantry-unit since it is the cheapest unit.

-#-

The code for the Keep (including changing Flags , movement of the Flags, "housekeeping"  (which side , how many infantry, etc. ) is now complete.

-#-

Animation strip for the unit-orders is complete too.
Next up is the buy-list : select the unit / order from the buy-screen.
I need three versions:
- 1 for full screen,
- 1 for splitscreen - horizontal
- 1 for splitscreen - vertical

S'all for now,
More new soon    
 

Hi all,

A small post this time.....
 
The AI is coming along fine. There are bucketloads of checks at the moment.
The enemy can do a number on things based on info that is generated every 5-10 secs.

All tasks are prioritized, so..., based on aforementioned info, the enemy-AI decides what action to take.

The most obvious checks are as follows:

How much money do I have ?
How many units do I have ?
How many units of a certain unit-type do I have ?
Does the selected unit have the appropriate order for the current task ?
Am I close to a base if I want to regenerate energy ?
Is my Main Base being attacked by the Player ? 
How many friendly Keeps do I have ?
How many units does the player have ?
How many Keeps does the player have ?
How many player units are in a certain area ?
..and many more...

There are a couple of tasks that go into the "sneaky b@st@rd" department. 
I hope to have a small demo ready , very soon.

Stay tuned peeps.



   

More stuff complete:

I've secured the bitmaps of the original unitorders.
We'll use these as placeholders, just to get the ordering-system up and running.

-#-

Finally completed the Spell-Tower model, it looks like a rook with a roof.
Also complete:

- code for 3D-Lightning ,to go with the spell-tower.

- code for shooting arrows with an arc , also for the spell-tower.

- code for updating the bases: it checks how many bases each team has, and calculates money-distribution accordingly

- function for all units:
  step 1 - distance-check to all bases from current position of unit
  step 2 - sort distances from nearest to furthest
  step 3 - pick first base from the top that is not the same color of the current unit. It returns the Base-Number

This function can be used for the orders:
- ENTER BASE
- SECURE BASE

(Thought for extra code for step 3 - in the event that all bases are friendly:
The order of ENTER BASE (infantry) or SECURE BASE (all other units) is changed to MAIN BASE ATTACK ) 

-#-

I've made a small test with 2x50 units (50 units for each side) moving about.
It's very unlikely that there are 100 units onscreen at one time, but this is a worst case scenario.
Anyway, it's running at 60 frames+ per second. So that's nice then

-#-

Observation: infantry-units that occupy bases are NOT counted towards the total number of 50 units.
Imagine this, 9 bases with 4 units each ( 9 x 4 = 36 units )
This means you could only field 14 more units (50 - 36 = 14 )

That's all for the moment ,
Stay tuned            

Awesome 

If we assume for now that the god unit flies around as a supreme being or can take shape in the "real world" on land, we have the transform function of the original plane-robot unit of herzog zwei.

I had that problem too,  so that's solved then. 

-#-

In the case of God-Unit Zeon: If we use only the Head of Zeon, then he would only be
able to "float", but if we decide to incorporate it's body too, then he could float as a head and walk, using it's body.

In the case of God-Unit Volcanon: I could make the model so that he flies, flapping his wings, and when he lands he just walks , like a normal bird does.

-#-

I say , we keep the God-Units. The concept sounds great.
(I was thinking about using Volcanon and Zeon too. Happy that we're thinking along the same lines.    )

Boat: Merman (throws tridents to give range)
Motorbike: Thief (fast, weak, melee)
Nuke: Wizard (weak, can hit gods in flying form because they use magic!)
Tank: Knight (Strong, melee only)
Armoured Car: Archer (Weak, ranged)
Infantry Soldier: Soldier (weak, melee only)
Support Vehicle: Healer (no weapon, just heals/ gives provisions / weapons)
Cannon: Tower (is the equivalent of an unmovable wizard + archer combo with heaps of armour)

Your suggestions for the units are very good. I say we keep 'em!
I have an idea on how the Cannon\Tower unit should look. I'll make a model of this one.

The idea of having 4 units occupying the Keep , has my vote. (Yes, it was only the INFANTRY who could this)

We could use torches with a Red or Blue aura to represent which side has taken control over the Keep, or indeed .....4 flags.

To use totally different units for EVIL sounds very good to me. We could have a KAISER CRAB instead of a TANK, and a LASER EYE instead of a CANNON ?

The story sounds great.  Please continue.. it reads very well to this point.

The use of a HEALER/SUPPLY TRUCK is a great solution. I could program it in such way, that, in case it gets attacked by the enemy, it would run to the nearest friendly unit.
So the enemy chases its target, and ends up being a target itself.

Oh.. wait .. I remembered  that there was a limit of 50 units per side. Perhaps we could use that too ?

Everything is going well, from the looks of it...GREAT 

Outstanding .

I've already "pseudo-coded" a number of orders 

Attack Main Base    (ordercost:  3500 G )
Secure Base            (ordercost:  1500 G )
Enter Base              (ordercost: 1800 G )    
Attack On Sight       (ordercost: 1000 G )
Patrol                      (ordercost: 500 G )

To do:

Stationary (ordercost: 100 )
Supply (ordercost: 580 )
(unless we decide on mechanized units, we could ignore this entry (?!)

Also, it's time to give my physics-wrapper a run for it's money.
I've started working on geometry that's suitable with JV-ODE (The Blitz version of the Open Dynamics Engine)

(visit www.ode.org for more information about ODE)

On the Dark Resurrection-front: More AI in pseudo-code, this is going great as well .
(more news as it happens)

Elvenfyre, thank you for your efforts so far.   

Awesome.... Just take your time. I'm not going anywhere.
In the meantime: have a look at my new screenies.



I was just curious how many polygons it takes to render a number of Keeps.
Total polys rendered: see top left of screenie.



Keep 'em Close (geddit ?  )