Jump to content

Just trying to get started here


Recommended Posts

I'm trying to get my feet wet with Jagstudio here and I checked out some of the demos but I'm getting stuck already on the dumbest thing. I have some programming experience - mostly python and then some Java and C++ back in school some years back. I made a pong game once.


In any case, I was looking at the debugview basic demo and I'm not having a lot of luck getting it to who what I want - in particular just displaying the screen coordinates of that little bug guy. I tried to get that debug box to print a line with the value for sprite[sprBugIndex].x at the bottom there instead of "This is some debug text" but nothing showed up. So then I tried just printing it right to the screen with rapPrint but that didn't work out too well either. A text string would print fine but it doesn't seem to want to print the x and y properties I'm looking for and nothing shows up.


So then I thought maybe I need to cast it to a string and the language doesn't like me treating ints as strings. I looked in the docs and saw there's a jsfPrintInt and that actually printed some sort of number for sprite[sprBugIndex].x but it was ridiculously huge and had a lot of digits. My jaguar window isn't anywhere near that many pixels wide. Neither is my real monitor for that matter so I don't know what number that is meant to represent.


So then I went back to the reference manual and I see there's this rapNumToStr command, but the example seems to be about a different command. "Example: bin2asc(987,2,out$)" so does that mean I would need to use bin2asc()? And I would have to store the value in a variable such as out$ and I couldn't just use it without that parameter in a print statement or elsewhere? Something like, rapPrint "Here 's the x coordinate: " + bin2asc(sprite[sprBugIndex].x,3)


Sorry for the long post. I don't mind working through my issues and figuring things out but I've been spinning my tires on this for a good while so I thought I'd try to get some help. Hi I'm Dave btw. Please go easy on me.

Link to comment
Share on other sites

Hi and welcome!


Sorry this is going to be brief as it's a flying visit from me.


The X and y coordinates are in 16.16 fixed point integer format. Therefore if you just view the number, it will be very large. You have a few options;


1. Shift the number right by 16 (eg. xpos>>16)

2. Use the other property sprite[].x_  (This auto shifts the number for you)


The bin2asc stuff..... We might have just forgotten to update that part of the docs for the new command.


But yeah, down shift the number and use rapPrintInt



  • Thanks 1
Link to comment
Share on other sites

Thanks for the reply. I'm bumping up against a couple of other things as I try to get my bearings here.


In the debug example, the bug sprite is totally off screen when I place the sprite at the screen coordinates (0,0). The Y axis seems fine but it is off screen on the X axis and it looks like (15,0) is the top left corner (per the first screenshot). I thought maybe it had to do with the sprite width but it always seems to be 15 pixels off regardless of the sprite I use - and it doesn't make sense to me that it would only apply to the X axis and not the Y.


Also, as I was playing around, seeing what I could do, I tried to draw a box - thinking maybe if it went well I'd turn it into a function for the project I'm planning.

boxX = 17
boxY = 15

jsfColour 2
		boxX = boxX + 1
	boxX = 17
	boxY = boxY + 1

It worked as expected (screenshot 2), but then when I increase that "REPEAT 62" to a "REPEAT 63" it fills most of the screen up with red and it stops responding to controller input and seems generally locked up (screenshot 3).


Any help is appreciated and I swear I don't think I'll need TOO much more handholding.






Link to comment
Share on other sites

Ok my next issue is dealing with the clut. I tried to look around the forum and there's a lot of useful info but I can't seem to crack this one.


I have a 4 bit, 32x32 road texture graphic I want to use. These are what I assume relevant parts in rapinit.s . If there's something useful I left out, let me know.

    dc.l    32                               ; sprite_width                  ; width of sprite (in pixels)
    dc.l    32                               ; sprite_height                 ; height of sprite (in pixels)
    dc.l    0                                ; sprite_coffx                  ; x offset from center for collision box center
    dc.l    0                                ; sprite_coffy                  ; y offset from center for collision box center   
    dc.l    32/2                             ; sprite_hbox                   ; width of collision box
    dc.l    32/2                             ; sprite_vbox                   ; height of collision box
    dc.l    ROAD_1                       ; sprite_gfxbase                ; start of bitmap data
    dc.l    4                               ; (BIT DEPTH)                   ; bitmap depth (1/2/4/8/16/24)
    dc.l    is_RGB                           ; (CRY/RGB)                     ; bitmap GFX type
    dc.l    is_opaque                         ; (TRANSPARENCY)                ; bitmap TRANS flag
    dc.l    32*32/2                          ; sprite_framesz                ; size per frame in bytes of sprite data    
    dc.l    7                                ; sprite_CLUT                   ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
    dc.l    32/2                             ; sprite_gwidth                 ; GFX width (of data)

And the line from assets.txt...


And then in my bas I tried doing this...


...but it wasn't obvious to me that's the right way to go about it. I was just looking at the examples and it seems to be the case that whatever you have in your rapinit.s file for the "sprite_gfxbase" can have its clut referenced by appending "_clut" to that sprite_gfxbase property? That is, couldn't find much in the way of anything explicitly saying that's how to get the "pallet address" mentioned in the reference manual.


But then I thought maybe I should also (or perhaps instead) do something like this...

sprite[1].CLUT = 7

So assuming my sprite index is correct, which from what I can tell seems to be true, that didn't help. I attached a picture that shows what it actually looks like side by side with what I would love for it to look like.



Link to comment
Share on other sites

Well, the Details tab on the Windows file properties reports the bit depth as being 4. I exported it from Gimp and it will tell me my image has 16 colors but not necessarily the properties of an exported file. Is there a more authoritative way I should check?

Edited by groovis
Link to comment
Share on other sites

I think you're onto something. I checked my file and it was 714 bytes. There don't seem to be a lot of settings when exporting a bmp from Gimp, but one was "Run-Length Encoded" and I turned that off and it gave me a 630 byte file. Still not 512 but headed in the right direction - and so far it seems to load ok now. Does that seem fine or should I really look into using something else to avoid future file weirdness?


Edited to add: Thanks for the help on this and same to those other fellas that had some tips. Hopefully it won't be too long until I have something to show.

Edited by groovis
Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...