Getting Pixel colours

[Sporadic]

Hi all,

 

First post here so first of all I wanted to say hello!

 

I've been having a play around with Raptor Basic+ and it looks promising. Very nice idea and a good way to get people into some Jaguar programming.

 

The tutorials were straight forward to follow and i've had sprites on the screen etc.

 

I have recently been messing around with the PLOT function as a way of drawing pixels to the screen.

 

What i'd like to know is if there is a way to get the colour of a pixel from the screen (where the PLOT has drawn to) using x,y coords?

 

I had a play around with the PEEK commands, thinking that I could get it that way by using the address of the sprite_gfxbase of the particle layer. I had some limited success but couldn't really get it to do what I would expect. When it comes down to it, I don't really have the knowledge in that area.

 

Any help would be great and thanks for reading.

 

cheers, Rik

Edited May 20, 2015 by Sporadic

[ggn]

Hi, and sorry for taking so long to reply - been busy with way too many things .

 

It's true I didn't code in a getpixel() routine, mostly because we never had a need for it, and I'd be interested to hear what you need it for tbh! But a request is a request, here's the code that will do what you need:

 

 

 
function getpixel(x as short, y as short) as unsigned short
if x band 1 then
function=(peek(strptr(RAPTOR_particle_gfx)+x/2+y*160)) band 15
else
function=((peek(strptr(RAPTOR_particle_gfx)+x/2+y*160))>>4) band 15
endif
end function
 

 

But if you try this as-is, the compiler will complain because we don't expose RAPTOR_particle_gfx to Basic itself. So head over to include\rbasic.h and add the following line to the file:

 

 

extern void *RAPTOR_particle_gfx asm("RAPTOR_particle_gfx");

 

This will enable the above function to compile properly. So you can now paste it inside your source code and just do c=getpixel(x,y) to get the colour of the coordinates you supply. Simple, right? . What I do there is check if x is odd or even, because since we're using 4 bitplanes mode for the particle/text layer each pixel is packed in 4 bits. Then I just peek into the byte the pixel is contained, and either mask out the value or shift the value to the lower bits and then mask that. I know it's a bit sloppy syntax and needs some trial-and-error, but I hope you bare with it for a little while!

 

In any case, have fun!

[Sporadic]

Excellent, thank you ggn!

 

That function is perfect, exactly what I was looking for. I added in the code as described and it worked straight away.

 

I then had a thought, I had some code from when I was messing around for getting the memory address and tried it out - that seems to work too. This means I don't have to modify the rbasic.h source code;

First I grabbed the address from the particle layer asset;

DIM mem%
mem%=RGETOBJ(0,R_sprite_gfxbase)

Then modified your code as below, just plugging in the mem% variable;

function getpixel(x as short, y as short) as short
	if x band 1 then
		function=(peek(mem%+x/2+y*160)) band 15
	else
		function=((peek(mem%+x/2+y*160))>>4) band 15
	endif
end function

I'm just playing around to try out stuff, using the GetPixel as collision detection. I know this could be done other ways with an array etc but thought it might be cleaner to just check the pixel colour directly. It's not exactly a hardware taxing game

Here's a picture of what i've created so far to make it clear what it's for (pic hosted elsewhere). Red line around the edge is a wall, orange line is player 1.

As a side note, not sure if this is a bug, I can log in the other thread if you like - but it seems to be plotting a black pixel directly to the left of the actual pixel I am plotting.

This can be seen in the above picture by the horizontal lines that have been drawn left to right.

I wondered what it was at first thinking I must have been adding 2 to the x coord but that's not the case.

As i'm using the getpixel for collision, it means that if you're lucky you can zoom through the dotted line if you happen to line up with a black pixel or when travelling right to left you just go through yourself because the pixel in front of the "bike" is always black.

Anyway, thanks again for your work. It's been fun messing around so far. I have also added a second player to above game and would like to keep fleshing it out.

Rik.

Edited May 23, 2015 by Sporadic

[+CyranoJ]

I'd say the pixels are being MOVE'd to the screen, instead of OR'd.

 

ggn?

[ggn]

Nope, the pixels were getting masked and ORed but the mask values were wrong - d'oh!

 

Just pushed the fix to github/bitbucket, you can just grab include\basic_functions.o and things should be fixed - sorry .

 

 

 

P.S. glad to read you're having fun with this!

Edited May 23, 2015 by ggn

[Sporadic]

That did it. Nice solid lines now

 

Thanks again. If I get anywhere with a game then i'll be sure to post results etc.

 

There is something else I have noticed but I cant give enough detail at present. If I can at some point i'll try post an example in the bugs thread.

Basic details though, the game runs fine, but sometimes (depending on how much plotting i've done) the emulator shows a scrambled screen and closes down. I don't know if i'm just overloading something, no idea.

 

Don't worry about it for now because it could be that I messed up elsewhere and it's not a bug at all.

 

As I said, if I can produce an example .bas file to replicate the error then i'll post in the bugs thread.

 

 

cheers,

 

Rik

Edited May 24, 2015 by Sporadic

[ggn]

That did it. Nice solid lines now

 

Thanks again. If I get anywhere with a game then i'll be sure to post results etc.

Yeah, a light cycles clone on jaguar got us thinking a bit! What if the text/pixel layer is defined as zoomable and it starts zooming in and out, focusing at the player's position in game? Or maybe some nice particles to spice things up? Or some glowy stuff (CRY/RMW mode)? Or or or... .

 

There is something else I have noticed but I cant give enough detail at present. If I can at some point i'll try post an example in the bugs thread.

Basic details though, the game runs fine, but sometimes (depending on how much plotting i've done) the emulator shows a scrambled screen and closes down. I don't know if i'm just overloading something, no idea.

 

Don't worry about it for now because it could be that I messed up elsewhere and it's not a bug at all.

 

As I said, if I can produce an example .bas file to replicate the error then i'll post in the bugs thread.

 

 

cheers,

 

Rik

Off the top of my head, maybe you're plotting outside screen boundaries and overwriting ram, causing everything to explode? Just a guess of course

[Sporadic]

Yeah i would love to get some funky graphical effects in there. I guess I'll keep playing around and see what happens. To start with i have just been getting the main mechanics done and getting familiar with it all.

 

I'll check your suggestion about the crash, it sounds like a good place to start.

 

cheers

[Sporadic]

Off the top of my head, maybe you're plotting outside screen boundaries and overwriting ram, causing everything to explode? Just a guess of course

 

I just had a play around and have managed to stop the crash.

 

In the sub shown below, I ended up having to add the 2 vsync calls to fix it. Once after the CLS and once between the while loops.

 

The first while loop draws the top and bottom walls and the second while loop draws the left and right walls.

This sub never crashed when first used, only after game over and pressing a joypad button to start again.

Could it be that something was overflowing with all the plot calls within the while loops and now, calling the vsync twice is flushing it out? I've no idea how anything works in the background so just giving my impression.

SUB setupwalls
	ax = ax1
	ay = ay1
	CLS	
	vsync
	
	COLOUR(wallcolour)

	WHILE ax < ax2
		PLOT(ax,ay1)
		PLOT(ax,ay2)
		ax+=1
	WEND
	
	vsync

	WHILE ay < ay2
		PLOT(ax1,ay)
		PLOT(ax2,ay)
		ay+=1
	WEND
		
	RLOCATE 120,0
	print "LaserBikes"
END SUB

[ggn]

Well, I copy-pasted the code above to a test project and called setupwalls. The only way I could get it to crash was by not setting basic_r_indx and basic_r_size. I assume you're setting those somewhere in your project?

 

The other thought I have is that maybe you're using RUPDALL and VSYNC as well? Not sure what happens then.

 

In any case I'd say that if it works that way then leave it as is and move on - alternatively I'd ask you to post the full source + assets so I could take a look. But like I said, probably move on and we can take a look at this at a later time.

[Sporadic]

Well, I copy-pasted the code above to a test project and called setupwalls. The only way I could get it to crash was by not setting basic_r_indx and basic_r_size. I assume you're setting those somewhere in your project?

 

The other thought I have is that maybe you're using RUPDALL and VSYNC as well? Not sure what happens then.

 

In any case I'd say that if it works that way then leave it as is and move on - alternatively I'd ask you to post the full source + assets so I could take a look. But like I said, probably move on and we can take a look at this at a later time.

Hi, yeah I am setting the basic vars and not using rupdall.

 

That's fine, I am more than happy to leave it as is. If a big problem arises then I will provide source etc.

 

I would rather move on and build up the game more and only revisit this if needed.

 

Cheers for your time,

 

Rik

[saboteur]

Sorry to revive this but in my quest for alternate collision detection methods I though i'd give the getpixel function a go.

 

However I get a bunch or errors when compiling which i'm guessing are c related.

Compiling C code...
build\drawmap.c: In function 'void basicmain()':
build\drawmap.c:1108:36: error: invalid conversion from 'void*' to 'int' [-fpermissive]
include/rbasic.h:98:12: error:   initializing argument 1 of 'int RGETOBJ(int, int)' [-fpermissive]
build\drawmap.c: In function 'short int getpixel(short int, short int)':
build\drawmap.c:1236:17: error: 'volatilechar' was not declared in this scope
build\drawmap.c:1236:30: error: expected primary-expression before ')' token
build\drawmap.c:1242:18: error: 'volatilechar' was not declared in this scope
build\drawmap.c:1242:31: error: expected primary-expression before ')' token
Build error!

I'm not even calling the function at this point - any ideas. ?

 

cheers

[ggn]

Right, thanks for the report, it's been now fixed! Sync your git repositories and you'll be fine.

 

To test it I modified getpixel to

 

 

function getpixel(x as short, y as short) as unsigned short
    if x band 1 then
        function=(peek(strptr(scrbuf)+x/2+y*160)) band 15
   else
      function=((peek(strptr(scrbuf)+x/2+y*160))>>4) band 15
   endif
end function

 

So it matches the screen buffer address in the drawmap example. And to test it all I added this code after the map is scrolled on screen (before the pause happens):

 

 

for i=0 to 15
rlocate i*16,200
print getpixel(i,0)
next i

 

This will print the first 15 pixel values of the draw buffer, and it looks ok to me! So try it out and report back if there's any problems.

[saboteur]

Thanks GGN

 

Tested and working.