binary zoo
Welcome, Guest. Please login or register.
Did you miss your activation email?
January 16, 2018, 03:36:44 PM

Login with username, password and session length
Search:     Advanced search
30167 Posts in 1158 Topics by 194 Members
Latest Member: RobertHedge
* Home Help Search Login Register
+  binary zoo
|-+  Game Development
| |-+  Guest Dev Blogs (Moderator: JDog053)
| | |-+  TMC's - Old School RPG - Blog
Pages: 1 [2] 3 4 ... 25 Go Down Print
Author Topic: TMC's - Old School RPG - Blog  (Read 42924 times)
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #15 on: November 10, 2012, 01:31:30 PM »

Can you display the meshes used by the physics to make problem finding easier? I assume you can as it would be tricky to debug otherwise.
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #16 on: November 10, 2012, 10:46:42 PM »

Quote
Can you display the meshes used by the physics to make problem finding easier? I assume you can as it would be tricky to debug otherwise.

No.

I have to create a set of Blitz3d meshes and position and align them to the physics meshes in order to see what the physics is doing.
And i think thats the same with all physics engines.  Even the 2d ones.
At least the ones i've tried, which have been several.

Here is example code to create an ODE Sphere Physics object.

//ODE object Body ( Attributes such as velocity and position )
ode_physics_body = dBodyCreate(ode_world)

//ODE Body Mass ( mass of body )
body_mass = dMassCreate()
dMassSetSphereTotal(body_mass , 10 , radius) // Mass ID , Total Mass , Radius
dBodySetMass(ode_physics_body , body_mass) // attach mass to body
dMassDestroy(body_mass)

//ODE Geom ( ODE Collision Mesh)
ode_physics_geom_mesh = dCreateSphere(ode_top_level_space , geom_size)
dGeomSetBody(ode_physics_geom_mesh , ode_physics_body) // attach Geom To Body

//Blitz3d Visible Sphere Mesh (Blitz3d sphere meshes are the same size as ODE Spheres)
blitz3d_visible_mesh = CreateSphere()
ScaleMesh (blitz3d_visible_mesh  , geom_size , geom_size , geom_size)


And here is example code that would need to be called each frame to position and align the visible mesh to the physics mesh.

PositionEntity ( blitz3d_visible_mesh , dGeomGetPositionX#(ode_physics_geom_mesh) , dGeomGetPositionY#(ode_physics_geom_mesh) , dGeomGetPositionZ#(ode_physics_geom_mesh) )
RotateEntity ( blitz3d_visible_mesh , dGeomGetPitch#(ode_physics_geom_mesh) , dGeomGetYaw#(ode_physics_geom_mesh) , dGeomGetRoll#(ode_physics_geom_mesh) )



In fact, i use 3 sets of meshes.

The physics meshes.
The actual visible mesh that would be used in game and could be any graphic.  Say a house for instance.
Debug meshes.  Blitz3d cubes, cylinders and spheres.  And these are exactly positioned and aligned to the physics geom meshes so i can see exactly what the physics meshes are doing.



Update
----------

I've started my first editor for this game.

An object editor that allows me to load in a game mesh and position and align all the phsyics collision meshes to it.

I was going to make this editor part of the game for quick editing but realised the editor would be rendering all the game media as well as the mesh i would be editing.

Which isn't pratical and would cause some slow down.

So this particular editor is going to be an external one which will allow me to edit just one mesh at a time.

Then i can save out all the collision data to the same folder as the graphics mesh.

TMC
« Last Edit: November 11, 2012, 08:27:58 AM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #17 on: November 12, 2012, 11:34:16 AM »

And TMC is onto his editors already. Smiley  You put me to shame man.

I have to create a set of Blitz3d meshes and position and align them to the physics meshes in order to see what the physics is doing.
And i think thats the same with all physics engines.  Even the 2d ones.
At least the ones i've tried, which have been several.
Sounds like a lot of work. For 2D physics AGK uses Box2D and can display physics bodies and forces on screen although I don't know whether that's an AGK thing or it's already in Box2D.

 
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #18 on: November 12, 2012, 05:54:29 PM »

Quote
And TMC is onto his editors already.   You put me to shame man.

 Grin


Quote
Sounds like a lot of work. For 2D physics AGK uses Box2D and can display physics bodies and forces on screen although I don't know whether that's an AGK thing or it's already in Box2D.

Thats interesting.

I suspect thats part of AGK.

Thats a very useful feature to have already included.

Should make using the physics system relaitvely easy.   Cheesy


Update
----------

The editor is comming along really well.
And i've got a lot written already.
It's probably 75% complete at the moment.
And is pretty easy to use.
Should get it finished this week.

I've also re arranged my collision system yet again.
This time i've done away with 2 sub spaces (jumpable space and non jumpable space) and have now just the one sub-space.
All my static game objects will go into this sub-space which has the advantage that no collisions will be performed between the static objects, but only between characters and static objects.
This should give some big fps savings.

The previous method would have tested sub-spaces against each other but disabled all collisions within a specific sub-space.
A less efficient method basically and seems to be a limitation of the ODE engine.
I couldn't find a way to disable sub-space to sub-space colliisons.   Tongue

Now each object has an attribute which says if the object can be jumped off.
Again it allows me to climb trees and other specific geometry and not others.

It's a case of trial and error and refining the system until i get something that suits my needs.

TMC
« Last Edit: November 12, 2012, 05:59:19 PM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #19 on: November 12, 2012, 09:10:03 PM »

It's a case of trial and error and refining the system until i get something that suits my needs.
I would imagine it's one area where you will be tweaking well into the project.  Once a feel for the gameplay starts to emerge you will no doubt have new physics based ideas that will necessitate change.  That evolution is what makes dev so fun.  Smiley
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #20 on: November 15, 2012, 01:56:54 AM »

Quote
That evolution is what makes dev so fun.


 Tongue

Update
----------

Editor coding is going really well.

Got loading and saving in there now as well as menu and quick editing mode.

I can load in a game mesh now, create and place the collision geoms where i want over the game mesh and save out the collision data.

Just need to code a test mode now where i can run around and jump on the object to test all the collisions as i would in game.

I did find one strange bug though, that happened when i deleted an object.
The visible debug mesh sort of changed type.
I've no idea why and it's never happened again.
Despite numerous attempts to repeat the bug.   Tongue

It's not important since it's just an editor bug.
A game bug would be different.  I'd take the time to track it down and nail it.


I've been playing Skyrim a bit lately.
Still finding new stuff to do and explore.  Such a massive game.

And really liked the ground based dust and snow clouds in the game.

So i decided to add some dust clouds to my game.

The code works and looks really good except for the fact it hits the fps really badly.
It's full screen alpha blending (transparency) that kills it.
So it has to go.
Maybe i could use it as an option for max detail mode.  But since my relatively quick pc struggles with it i expect most other systems would also.

It's really depressing though.
My PC can handle Skyrim no problem, although i turn off Anti Aliasing and run the game in 1024 x 768 mode.
The amount of polygons and graphics it shifts in Skyrim is amazing and my game struggles with just one or two thousand polygons.   Tongue

Just shows how slow Blitz3d really is.

And my game uses a lot of optimisation techniques as well.
It's not as if i havn't bothered trying to speed things up.

I have to temper my ambitions to create more impressive graphics.
It has to remain fairly basic to keep the fps up.

And as such, i call it a 'Retro RPG Game'.   Tongue

TMC
« Last Edit: November 15, 2012, 02:01:41 AM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #21 on: November 15, 2012, 10:10:52 AM »

And as such, i call it a 'Retro RPG Game'.   Tongue
That sounds like a good thing to me  BunnyMonkey!


For all me saying retro is a good thing, it would be a shame if those performance issues impacted on your grand design.  Any thoughts on what might be causing it (physics?), whether you can improve it or even whether you are tempted to look at another language again?
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #22 on: November 15, 2012, 01:55:04 PM »

Quote
Any thoughts on what might be causing it (physics?), whether you can improve it or even whether you are tempted to look at another language again?

Blitz3d is based around Direct X V7.0, so uses old technology and architecture.

It's not able to support shaders or vertex buffers or any of the modern day hardware that really takes advantage of the speed on offer nowadays.

It's really the polygon count that hits the fps the most.

I was doing a lot of speed tests last night and found that the physics doesn't affect the fps nearly as much as the polygon count, especially since 99% of all the physics objects will be static and not moving.

Writing a complete game looks possible at the moment but i wouldn't be surprised at some future date if i had to abandon it because of some impassable fps issue.

If that happens i guess i would be forced to jump to a new ship.

TMC
Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #23 on: November 16, 2012, 08:08:05 AM »

Blitz3d is based around Direct X V7.0, so uses old technology and architecture.
Is DirectX 7 still fully supported?  IIRC there were problems with it on Vista and I wouldn't imagine it's any better of W7 (we wont mention W8).
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #24 on: November 16, 2012, 12:34:35 PM »

Quote
Is DirectX 7 still fully supported?  IIRC there were problems with it on Vista and I wouldn't imagine it's any better of W7 (we wont mention W8).

Here's a quote from the Blitz3d Product page.

"Requirements: Windows 95/98/ME/2000/XP/Vista/7; Hardware accelerated video card; DirectX7 or greater."

And apparently it's works on Win 8 as well.

I'm still using Win XP, so can't test other Operating Systems until i release a demo.

TMC
« Last Edit: November 16, 2012, 01:22:59 PM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #25 on: November 17, 2012, 01:10:39 PM »

Yeah a little googling seems to indicate that DirectX7 should work on newer OS's although your users will need to use compatibility mode.  Also Dx7 seems to be emulated on these systems so performance might be worse than in XP.

I have a decent Vista desktop if you want me to run some quick speed tests.  It might be worth it given the performance issues you've encountered already?
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #26 on: November 18, 2012, 01:19:23 AM »

Quote
I have a decent Vista desktop if you want me to run some quick speed tests.  It might be worth it given the performance issues you've encountered already?

Yeh, thanks Fog, that would be very useful.   Smiley
Much appreciated.

I'll put together a demo and let you know when it's uploaded.


Update
----------

Object Collision Editor is all but complete now.  ( See attached screenshots. )
Unless i can think of any new features i want to add.

The coding has been really straight forward and i was able to port a lot of code from my Zytron II editors across which really speeded up the dev time.
Routines like loading and saving were basically straight ports.

A feature missing in Blitz3d that was really useful in Blitzmax was the ability to print text to the screen with a black background.
So it can be easily read no matter what is displayed for the background image.
It's not very aesthetic, but does make for easy reading for my editors.
Reading text can be pretty difficult without a black background as white text on a white background can almost disappear.
So i spent some time writing a general 'drawtext' routine which works out the length of the text and draws a black background rectangle first before drawing the text on top.
This gives me the same functionality as Blitzmax now.


The editor allows me to load in any 3d mesh and position and align ODE collision meshes to it.
It's well featured and pretty easy to use.
I took some time fine tuning the controls to make it as easy to use as possible, as i expect to be using this editor quite a lot as i build up a library of 3d objects.
I also included 2 test modes so i can run around the level / mesh and test out the collisions as i would in game.
All seems to work ok and the saved data is really small.
My test house comes out at about 600 bytes for the collision data.


I was going to include some shadows code within this editor, but after giving it some thought i realised it would be better to leave the shadows for my world object placement editor instead.
The shadows i'll be using will be textures applied to a flat plane, placed underneath each object.
Which is what i do for my tree shadows.
But this means i can't rotate my 3d objects to any yaw angle in game because it would mean i would need a lot of shadow textures (one for each angle, 0 - 360) which just isn't pratical.
So i'm going to restrict the yaw angles of the 3d objects to the eight points on a compass.  Giving me eight different yaw angles.
This should provide enough variation for object placement and only restrict me to eight shadow textures per 3d object.
I think it's a fair compromise.
So when i come to place a 3d object in the world, i can choose 1 - 8 different yaw angles for it and select the relevent shadow texture for that angle.
And this will be reserved for my 3d object world placement editor.

Next i've got to update my actual game code to use the new collision data and to get the objects in game.

TMC


* 1.jpg (118.21 KB, 1024x768 - viewed 220 times.)

* 2.jpg (138.57 KB, 1024x768 - viewed 224 times.)

* 3.jpg (128.59 KB, 1024x768 - viewed 214 times.)

* 4.jpg (101.02 KB, 1024x768 - viewed 210 times.)
« Last Edit: November 18, 2012, 07:12:14 AM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #27 on: November 18, 2012, 11:25:43 AM »

That's looking like a feature rich editor already.

Quote
So i'm going to restrict the yaw angles of the 3d objects to the eight points on a compass.  Giving me eight different yaw angles.
This should provide enough variation for object placement and only restrict me to eight shadow textures per 3d object.
I think it's a fair compromise.
Yeah I'd guess 8 different orientations is a decent compromise.  I doubt very much it will even be noticeable in game.

Do you create the shadows in a modelling app and then export them or is it a Paint Shop job?  Not the sort of problem I've ever had to tackle for obvious reasons Smiley
Logged

T_M_C
1000 XP
*
Offline Offline

Posts: 3000

TMC


View Profile Email
« Reply #28 on: November 18, 2012, 05:30:48 PM »

Quote
That's looking like a feature rich editor already.

 Smiley


Quote
Yeah I'd guess 8 different orientations is a decent compromise.  I doubt very much it will even be noticeable in game.

Yeh, thats what i thought.


Quote
Do you create the shadows in a modelling app and then export them or is it a Paint Shop job?  Not the sort of problem I've ever had to tackle for obvious reasons

Well, the mesh itself is created from code.
Blitz3D allows the programmer to create any kind of mesh by creating verticies, uv's and triangles and surfaces.
So thats what i do for my planes.  Which are also used for billboards.
I don't however create a new mesh that way each time i need a new mesh, but create one version of it when my code is initialised and hide it, then do a 'copymesh' command each time i need a new instance of it.
It's much faster copying a mesh than it is to create it afresh each time.

The actual shadow textures will probably be photoshopped screenshots of the model on a black background taken from the various compass angles.
Ramp up the gamma of the model image until it's as white as it can be on a black bakground.
Manually fill in any gaps and edit any stray edges.
Flood fill the image with a near black color.  Not black ( rgb 0 ,0 , 0) as my shadow textures are mask textures where black isn't drawn.
And i'm good to go.
It's a simple process i've used in the past that works quite well.


Update
----------

I've changed my mind again and decided the shadows code needs to be in my object editor now.
So i can position and scale the shadow mesh to suit each object angle.
Then port across the code to my game.

Today i ported across my external change screen res setup.exe programme i used for Zytron II.
Modified it to suit my new game and gave it a thorough testing.

This lets the user select his desired screen res and fullscreen or windowed mode.
I don't seem to have an option in Blitz3D to force a refresh rate, so that part of the set up programme has been removed, although i'm doing some research on this as we speak.
Along with any sound setup options, as Blitz3D doesn't have them.
Also looks like i'll have to implement some delta timing code for the game too because of this.
Where the display is updated independantly of the game speed.  (or more accurately, the game speed is modified on the fly depending on how much real time has elapsed between frames)
But that shouldn't be a problem.

TMC
« Last Edit: November 18, 2012, 05:32:39 PM by T_M_C » Logged
fog
Zookeeper
1000 XP
*
Offline Offline

Posts: 13178



View Profile WWW Email
« Reply #29 on: November 19, 2012, 08:05:45 AM »

The actual shadow textures will probably be photoshopped screenshots of the model on a black background taken from the various compass angles.
Ramp up the gamma of the model image until it's as white as it can be on a black bakground.
Manually fill in any gaps and edit any stray edges.
Flood fill the image with a near black color.  Not black ( rgb 0 ,0 , 0) as my shadow textures are mask textures where black isn't drawn.
And i'm good to go.
It's a simple process i've used in the past that works quite well.
Sounds like you could write an app in Blitz to automate the whole of that very quickly.

All it effectively needs do is load a model against a white backdrop, capture camera views from fixed locations, check pixel colour of those captured images and change to (near) black where not white, save image.

Could be a serious time saver if you have a lot of models and therefore a lot of shadows to create.
Logged

Pages: 1 [2] 3 4 ... 25 Go Up Print 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines
Simple Audio Video Embedder
Valid XHTML 1.0! Valid CSS!