Sporadic Posted May 20, 2015 Share Posted May 20, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
ggn Posted May 22, 2015 Share Posted May 22, 2015 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! 4 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted May 23, 2015 Author Share Posted May 23, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted May 23, 2015 Share Posted May 23, 2015 I'd say the pixels are being MOVE'd to the screen, instead of OR'd. ggn? Quote Link to comment Share on other sites More sharing options...
ggn Posted May 23, 2015 Share Posted May 23, 2015 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted May 24, 2015 Author Share Posted May 24, 2015 (edited) 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 Quote Link to comment Share on other sites More sharing options...
ggn Posted May 24, 2015 Share Posted May 24, 2015 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted May 24, 2015 Author Share Posted May 24, 2015 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted May 25, 2015 Author Share Posted May 25, 2015 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 Quote Link to comment Share on other sites More sharing options...
ggn Posted May 25, 2015 Share Posted May 25, 2015 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. Quote Link to comment Share on other sites More sharing options...
Sporadic Posted May 25, 2015 Author Share Posted May 25, 2015 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 Quote Link to comment Share on other sites More sharing options...
saboteur Posted May 22, 2017 Share Posted May 22, 2017 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 Quote Link to comment Share on other sites More sharing options...
ggn Posted May 22, 2017 Share Posted May 22, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
saboteur Posted May 23, 2017 Share Posted May 23, 2017 Thanks GGN Tested and working. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.