Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Checking bitmap colour

Author
Message
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 25th May 2008 19:05 Edited at: 25th May 2008 19:07
I have a track which is textured onto a matix and I am trying to work out when I am on and when I am off it. So far I have come up with two possible ways to do so.

1. look on the screen to see the colour just behind the bike. if
it isn't grey then i am off the track.

2. Look on the bitmap which textures the matrix to see the colour.

Of the two the second seems most appropriate as in #1 if any object was behind the bike then it would think we were off the track.

I have managed to do number 1 with some great help from Latch. But I really feel that I should do number two. But I have two problems:

1. Point command is very slow (im not sure if there is a dll that could help me out there, probably is though)

2. It doesn't seem to work because when i come off the track in
the 3d world (the actual game) it doesn't seem to change the colour it picks up from looking at the bitmap usualy and it will change sometimes when I have been off the track for 20 sometimes more and it's not like it's 20 units out of sync with the image in the x axes and 30 units out in the y axes, it seems to be a bit random.

The Matrix is 500x500 and the image is 5000x5000. Baring in mind that the 0,0 on the matrix is the bottom left ahnd corner and on the bitmap it is the top left.I work out the colour of the position of the bikeposition on the bitmap using:


But it doesn't seem to work. Any ideas would be greatly appreciated. Thanks.


Codeeater
NanoGamez guy
18
Years of Service
User Offline
Joined: 13th Jan 2007
Location: Closer than you think...
Posted: 25th May 2008 20:59
Quote: "I have a track which is textured onto a matix and I am trying to work out when I am on and when I am off it"


You could make an array of the x and z co-ordinates of where the matrix has been textured with your image, and then calculate the tile that the bike is on in the matrix (using math) and find out whether that tile is textured or not.


What are the chemical formulae of:
Sodium Nitrate, Gallium, Manganese and Einsteinium
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 25th May 2008 21:52
Which is essentially what a Waypoint system is. Do a search for the word waypoint and you'll find lots of info.

TDK_Man

Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 25th May 2008 23:17
Quote: "Which is essentially what a Waypoint system is"


I thought waypoints are for AI. Im trying to work out when the player is on the track or on the grass next to it
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 26th May 2008 00:14
Ok,,, solved most of the problem. Basicaly when i have more than one segment to a matrix
it seemed to move he image that was being put onto the matrix along by about 25,,, but when I had 1 segment to the matrix it was right. so basicaly I had to -25 away from the x position. Does anyone know why this happens, i've solved th eproblem im just interested.

Now I need to find a way to have quick colour checking on a bitmap (rather than using point(x,y)). I know how to do it on the screen using a DLL, just not a bitmap.

Any one know any DLLs or anything of the sort that may help me here.

Codeeater
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 26th May 2008 00:51
Quote: "so basicaly I had to -25 away from the x position"

25 isn't necessarily "the golden number" in all cases. When an image is converted to a series of matrix tiles, texels (the converted pixels to texture point colors) are shaved off of each tile. Just how many and what format has to do with the size of the texture, the number of tiles in the matrix, the matrix texturing method, etc. This is actually meant to help blend the texture so it can be made seemless (I think).

You can actually reference the pixel color from a memblock based on your position on the matrix very similarly to how you would using the point command or similar function. This should be very quick.

If you use MAKE MEMBLOCK FROM IMAGE, (by the way, an image sized 5000x5000 seems unusally large to be used as a texture. That's like 25 megabytes for a single image alone... and using a memblock with it is gonna double that to 50 megs!) each pixel color can be referenced with



Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 26th May 2008 11:28
Cheers,,, I jus did a bit of trial and error to work out how much I should take away.

Ok i'll have a look into that. The only reason im using such a huge image for my texture is that i want to have fairly detailed terrain on the matrix. Would it make much difference if i changed it to 500x500?

Also I might have a different reference image to the one textured onto the track so i'll make that smaller.

Cheers,,,

Codeeater
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 26th May 2008 15:14
Quote: "I thought waypoints are for AI."


Yes they are, but you can use them for other things too.

You could have a set of waypoint markers running along the centre of the track for AI and another set each side of the track and use those just to calculate if a player is on it or off it.

TDK_Man

Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 26th May 2008 23:31
@TDK

The only trouble with that is that my track get thicker and thinner along the way.

@latch

I tried making the image 500x500 and it verybadly decreases the quality. would it slow it down very much to be 50mb? ( i hav never used memblocks before) I have attached pictures of the quality change.[img]null[/img][img]null[/img]

Attachments

Login to view attachments
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 26th May 2008 23:32
And this is it before

Attachments

Login to view attachments
Libervurto
18
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 27th May 2008 02:52
can you get pixel collision in in 3D like you can with tranparent sprites?
then you could texture a plain with an image of just the track and detect collisions to see if the bike is on the track.

It is far better to complete a 10 line program than to start a 10,000 line program.
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 27th May 2008 10:59
Quote: "I tried making the image 500x500 and it verybadly decreases the quality. would it slow it down very much to be 50mb? ( i hav never used memblocks before) I have attached pictures of the quality change.nullnull "


In terms of memory, when you make a memblock from an image, you are basically copying the image information to an area of memory you can manipulate. So if your original image is 25 megs, then you are going to create a memblock that is about 25 megs. Since the image will still be in memory, that means oyu are using 50 megs of resources. Don't be afraid of memblocks. They are basically like a big array, except that you view and edit information at Byte, Word, Dword, or Float positions. In an image, all the pixel information will be either WORDS or DWORDS depending on whether you are in 16 bit mode or 32 bit mode when the MAKE MEMBLOCK FROM IMAGE command was called.

The memblock method shouldn't slow anything down (depending on the system running your app. If the system doesn't have a lot of memory - you might run into trouble) . The method I proposed creates a reference based on the position of x and z converted to x and y of a 2d image. The reference jumps immediately to a memory position inside the memblock - sort of like an index in a database. The calculation takes the same amount processing power no matter how far it has to jump inside of the memblock because the position result is always only a single number (representing a color from a pixel in the image).

Unlike a DLL or the Point command that has to read a pixel from a screen and convert that into a useable value (RGB), the memblock method has all of these values already stored and you can index them based on the position calculation.

The concern I'm communicating is with the video memory. If you wanted to distribute your game and someone had a 64 mb video card, and you loaded just one 25 megabyte texture, that wouldn't leave a whole lot of memory to do much else graphic wise. With a 128 mb graphic card 4 or 5 textures of that size would eat up tons of video memory. I'm just throwing it out there for you to think about.

Make the game using your textures, test things out, see what works best.

Quote: "Also I might have a different reference image to the one textured onto the track so i'll make that smaller"

Not a bad idea.

Quote: "can you get pixel collision in in 3D like you can with tranparent sprites"

No, unfortunately. The initial collision radius is calculated based on the objects size and not it's transparency.

Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 27th May 2008 13:05 Edited at: 27th May 2008 13:07
I tried out the memblock idea and it doesnt really seem to work:

position=(x#-25)+(z#*5000)
position=12+(position*(2)
rem 16 bit depth
color=memblock word(1,position)


(x# is the x position of the bike but i must take away 25 as the matrix is slightly off set)

(z# is the z# position of the bike so its the y position on the image)

The memblock header size is 12(i think)
and the bytes per pixel are 2( im pretty sure)

when I used point it used to settle on a nuber when i went on to the track as the track was the same colour all around but now the number returned seems to be constantly jumping around as I move, not settling when I go on the track

Quote: "If you wanted to distribute your game and someone had a 64 mb video card,"


I don't really think my game is anywhere near a high enough standard to sell really.I just do it for fun.


Thanks!

Codeeater
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 27th May 2008 19:08


The formula is a little off. You're definitely using 16 bit right? because that makes a huge difference... Also, remember, you need an x and y position in a 2d image to reference inside the memblock, not the x and z of a 3d object. Just like you would have to convert the x and z to and x and y if you were using the point command, you have to do the same here.

So, if your matrix is 500 x 500 and your image is 5000 x 5000, the conversion might look like:



NOTE: I have to use the 5000.0 / 500.0 because I want to calculate a float value to be returned as an integer: xpos or ypos. If the size of the matrix were larger than the image I would use 500.0/5000.0 . If I used 500/5000, I would always get back 0 as the xpos and ypos because the integer portion of 500/5000 is 0. So, I need a float to return the proper percentage. After that, xpos, ypos and position are all integers because I only need to reference pixels which are expressed as integers and that should help keep things a little speedier. So for consistancy, I always use a float in the initial conversion formula. But, since 5000/500=10 you don't need to because it results in a nice and neat whole number : 10 . In fact, you could just use 10 without the division and that would add a bit of speed as well.

and then to look up the pixel position in the memblock:




There are a couple of things to be aware of. The color returned from the memblock in 16 bit won't match the value returned by the RGB() function. The short story, there has to be a conversion from a 2 byte color number to a 3 byte color number. Before you do anything, you'll have to get the color that the memblock returns. I didn't mention this before because I assumed you'd be using 32 bit depth which makes things nice and neat and easy. So, at the top of your program or somwhere early, get your track color as it would be read from the memblock:



Now you have your trackcolor as it would be read from a memblock. Understand? All I did was cleared the screen with the track color, got a single pixel, turned that into an image, turned the image into a memblock then got the first WORD value after the header (the first and only pixel in the memblock). We only have to do that once unless your track color changes. If you use a reference image, that makes things nice and easy because you can use solid colors without having small gradations and therefore only have to test for one color.

I wrote up an example when I proposed this a few days ago and it works. I don't think you'll need the 25 unit offset unless you've repositioned the matrix - but test it with and without.

If you need the full example, I might post it as a code snippet or something... for now, see if you can get it to work with the information you have so far. If you can get the hang of using the memblock, then you'll be armed with a whole new set of tools that'll give you a lot more options when programming in DBC. And depending on how you use them (memblocks), you can gain a lot of speed.

Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 28th May 2008 22:34
Thanks.

I still cannot get it to work. I have used your code completely, i've double checked i've used the right image.

Quote: "If you need the full example, I might post it as a code snippet or something..."


If it's not too much trouble can you please.

codeeater
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th May 2008 02:37
hmmmm... Maybe you can post the code and I can see where you are going wrong. You're sure you are using 16 bit? (SET DISPLAY MODE x,y, 16). I don't mean whether or not you created your image and saved it as 16 bit, I mean the mode you are running the app in. The memblock will always reflect the mode you are in.

Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 30th May 2008 12:03
It was using 32bit and now i've changed it to 16 and it still doesnt work how much code do you want, If i post the whole game it'll be about 800 lines or just the memblock code?

thanks

codeeater
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 30th May 2008 16:13
It can be 32 bit, it doesn't have to be 16 bit - you had mentioned that it was early on so I was trying to make sure you were consistant. If your mode was 32 bit, then you have to use 4 bytes and not 2 for the color. If it was 16 bit, then you would use 2 bytes.

Maybe it would be easier if I post the example. I was kinda hoping you'd figure it out though

The function, test_track() will return a 1 if the position in the memblock color matches the track color; a 0 otherwise. It also checks for the proper byte length by looking in the memblock header after the image is converted to a memblock.

I do an initial setup of the track color at the very top of the program. This is so that in 16 or 32 bit, the color can be matched in the memblock (a 2 byte versus a 3 byte number - very different values for the same color in 2 different modes). I'm also using only 1 color for the track. If your track is shaded, you'll have to adjust the color checking over a range. Remember, the comparison is the pixel value at a specific location in the image which you should have converted from the 3d world position.



Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 30th May 2008 23:16
Sorry i am not currently on a Pc with DBC so i cannot as yet test out your code. I will try it out asap.

Thats very similar to what I used except that i just used the number 5000 (the width of my image) rather than writing "wd=memblock dword(mem,4)" i presume that it would just be the same?

thanks,

codeeater
Pixelator
17
Years of Service
User Offline
Joined: 8th Jul 2007
Location: here
Posted: 31st May 2008 01:16
no offence latch but code eater id go with tdk if i were you.

Your signature has been erased by a mod. Reduce the size!
Latch
18
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 31st May 2008 01:30
@Pixelator
None Taken! Whatever works for you, that's what you should use!

@Code Eater
Quote: "wd=memblock dword(mem,4)"

Should be wd=memblock dword(mem,0) (width is the first position)

Quote: "i presume that it would just be the same?"

Yes, if the width of your image is exactly 5000. I use the lookup so it can be any size image if I want to change things. The way the snippet is written, you can change the display mode and it will still run, you can change the image and the matrix (just change the xpos ypos conversion for the proper sizes) and it will still work!

The cool thing about this method is, in your reference image you could have colors representing any kind of zone you want! As the vehile moves into a different zone (over a different color) you can have any kind of reaction you want without having to use collision. And you don't have to use a matrix if you don't want to - you could use a plain, just rotate it and offset it so it's lower left corner is at 0,0,0 so the 2d positions are easily calcualted from the world positions.

Enjoy your day.
Code eater
17
Years of Service
User Offline
Joined: 17th Feb 2008
Location: Behind You!
Posted: 8th Jul 2008 22:40 Edited at: 9th Jul 2008 12:36
Sorry for the hold up I've been busy with exams and school in general but I've sorted it.

This is goin to sound a bit stupid but basicaly the only trouble I had with your code was that I was using the Y position of my bike rather thatn the z position. lol.

Thanks for all the help,,, greatly appreciated.

codeeater

Login to post a reply

Server time is: 2025-06-07 06:41:17
Your offset time is: 2025-06-07 06:41:17