Messages

They're not major issues, but I noticed some unusual behaviour with breakpoints
* If you're on a line prior to one with a breakpoint and you delete your current line, when the next line (with the breakpoint) moves up one line, the breakpoint disappears.
*If you're on a line with a breakpoint and in the first column and press enter, the breakpoint doesn't move down a line as it should.

I'm contributing this here because even though it's really simple, I was surprised there was no command to return it directly.

If you have a number (eg. 63.45) and want to return the ".45" part only it's as simple as

Code (glbasic) Select Expand


FUNCTION FractionOnly : Number
Return (Number - INTEGER(Number))


This should be relatively simple but vectors are making my head hurt just now.

I'm looking at implementing steering behaviour (ie. gradually changing a vector to another one). Does anyone have pseudocode or an example they can throw in my direction?

The easiest way to describe it is with a car example :
Lets say I've got a car going North at 10 m/s. I want to change that so that the car is eventually going East at 10 m/s. Every game update the speed will be 10m/s. The player turns a steering wheel a certain amount so that every game update the car is facing a bit more to the east, a bit less to the north, but still doing the same speed.

My code currently has an initial vector and a starting point on a grid. I know when the player hits a particular location I need to start changing the vector so it gradually moves to point at a different location. I'm not sure of the calculation to set the new facing direction as I only know it as an angle from the current facing direction, not as a vector.

Edit - Just found that it looks to be
X=cos(angle) * speed
Y=sin(angle) * speed

Damn! I can't get it to crash now I've added a bit to my program! I'll keep trying and if I can reproduce it I'll upload the example code.
Sorry, I should've thought to do that when I posted the bug report.

Debug and debug-unaligned would be signed with a debug key.
The unaligned refers to memory alignment in the destination device.
The release version is the unsigned one (ie it hasn't been signed by a security key).

As noted on the initial post

By putting "END" commands straight after the "IF" and "ELSE" lines, I can prove it's the X_COLLISIONRAY on the first execution of the code that crashes the program.

I posted the actual code described by that code in response to metalthinks questioning whether it was one of the commands in the IF statement.

The result was definitely a crash with a "do you want to report the problem to Microsoft" query.

I'm not sure how the debug version would work - I can't see how you could introduce breakpoints and do a debug run of your code through an external IDE.

I had mostly dismissed the "split mesh into smaller meshes" plan as I didn't think it would give any savings when most tiles will change at various times (eg. a heavy snowstorm changes every tile to deep snow). What's probably obvious to everyone else - and hadn't occurred to me for some reason - is that the smaller meshes could be rebuilt in different game loops to spread the impact.

I'm not sure if the X_COLLISIONRAY statements will now add a lot more overhead as I'll have to do multiple checks rather than one, but hopefully OpenGL will know not to draw meshes that are off the screen and save cycles there.

Kanonet - if you want to lend any expertise here I'd be happy to hear it - my camera routine is pretty much a 6 degrees of freedom one (ie. it features tilt, zoom and movement so at any given time I might be zoomed so I can only see a few tiles, or zoomed out to see the entire mesh). I currently just do an X_SetTexture then a single draw object command.
I'm playing around with a few different ways to create the texture at the moment. Until I figure out the best way to do it, I'm currently just creating a 128x128 bitmap, drawing coloured pixels based on height at the correct location, then texturing the mesh with the image - 1 pixel per tile. I do want to do proper textures though rather than just 1 colour per tile.

Splitting the mesh might also change how I end up handling pathfinding on the terrain, I'll have to think about whether there are optimisations (or losses!!!) to be made there as a result too.... Hmmm....

No, nothing like powermonger (though it could easily be used for something similar). It's still a proof-of-concept at this point, I'll post details if it looks like I'm going to be able to produce the game I'm trying to.

Hi Erico,
1) This problem just fixed itself, but I'm not sure how. I'll repost if I can figure it out. Thanks anyway!!!
2) SMOOTHSHADING fixed that issue thanks! I didn't spot the command as it's not listed in the 3D commands help section. It should've occurred to me that the command would be relevant to what I'm doing as textures are 2D.

Cheers!

I'm trying a new approach to texturing a model (a generated 3D landscape) but I'm having some unexpected behaviour I'm hoping someone will be able to pinpoint for me.

Firstly my model is built as follows

• I load a list of heights of each square tile - the map is 128x128 tiles in size
• I create the model in triangle strips
• I load a test image to use for a texture that is 128x128 pixels in size
• The texture is set to the image that was loaded then the model is drawn

Here's what my model comes out looking like - this is a picture taken from looking straight down at the model. The lines aren't 100% straight as the section of the model shown isn't flat so I'm not worried about that.



Here's the texture. Each quad in my model correllates to exactly 1 pixel in the source texture.


Here's how I create the model

Code (glbasic) Select Expand

FOR Z=0 TO (ModelSizeZ-2)
ZTexValue1=1/(128/(Z+1))                      // Set the first Z offset into the texture image
ZTexValue2=1/(128/(Z+2))                      // Set the second Z offset into the texture image
X_OBJNEWGROUP

FOR X=0 TO (MapSizeX-2) STEP 2
XTexValue1=1/(128/(X+1))                      // Set the first X offset into the texture image
XTexValue2=1/(128/(X+2))                      // Set the second X offset into the texture image

      X_OBJADDVERTEX   X,   HeightsArray[X][Z+1],  Z+1,  0,0, RGB(255,255,255)         // Create quad. Bottom left corner
        X_OBJADDVERTEX   X,   HeightsArray[X][Z],      Z,  0,1, RGB(255,255,255)              // Top left corner
        X_OBJADDVERTEX   X+1, HeightsArray[X+1][Z+1], Z+1, 1,0, RGB(255,255,255)     // Bottom right corner
        X_OBJADDVERTEX   X+1, HeightsArray[X+1][Z],    Z,  1,1, RGB(255,255,255)         // Top right Corner
ENDIF
NEXT
NEXT

My issues
1) Any idea why am I getting the image coming out looking like it's made up of joined up strips? I would've expected everything to blend together nicely, but instead I get the lines in it where two strips of triangles meet.

2) Each tile (ie square of 2 triangles) should be a solid colour. How do I stop each colour from blending into the next one so that each square's doesn't blend into those of the squares next to it? Is this because of the small texture image size? (128x128 pixels)

Ah okay, when you were talking about the land being recreated before it didn't click to me that you were suggesting recreating the whole mesh each time to change the texture offsets.
I suppose that's doable. I was hoping more for a way to change one vertext without recreating the whole mesh to save the computational overhead. Failing that though recreating the whole mesh may be the way it'll have to go. Thanks Matchy!

I'll go with that unless anyone can suggest a way to change vertex information.

But importantly it has to be able to change reasonably frequently - I can make individual tiles a river now for example, but don't want to have them have to be a river for the whole game. I have to be able to make each tile change its texture while still having it part of the same mesh so I can run x_collisionray against it.

Please no OO!!!!!!!!!!!!!!!!!!!

Here's an actual screenshot. At the moment I've got it coloured based on height. I'm not sure why the colours are in bands running in 1 direction, it should be colouring in 2 directions. That's just temporary anyway until I get textures sorted. The theory is that every tile (tree's are every 2 tiles at the moment so that gives you an idea of the size tiles I'm working with) should be able to be changed based on how grassy it is. Lots of grass should be bright green. As it dries out, each tile will go towards dirt, and it should be able to have snow per tile etc.



It's exactly the same as the image from the previous post though, it should be able to be textured like a checkerboard potentially.