total noob RB+ programming question

[omf]

Today i decided to have my first play with raptor basic +

 

i decided to start very very simple, my goal was to display a background image and then have the default text that is in the template print on screen over the background.

 

so i examined the invader example for examples what i was suppose to be doing.

 

with this in hand i modified the assets.txt to add the background image in the same way as the invader example does, i then added a background object to rapinit.s using the code for the background object in the invader example., i then changed this as my image was 240x240 instead if 352x240

 

i added a do / vsync / loop section to the bas file and compiled

 

it to see if there was any errors.

 

to my astonishment the picture was displayed. I had not instructed the image to be displayed so how has this happened? also the text was not displayed (unless it was under neeth the image) ?

shouldn't you have to put a command in the bas file to display the picture and not have it display automatically ?

 

 

also there appears to be a bug in the np++ compile script, it needs to go up one more level so instead of \.. it needs to be \..\.. on the cd lines

[+CyranoJ]

If the background object was set to 'Active' in the rapinit.s file then it will be displayed, nothing needs to be commanded by BASIC.

 

Also, if it is defined after the particle/text layer, and it is set to opaque then it will appear over the top and obscure the text behind it.

[sh3-rg]

You'll be amazed at what you can make happen before writing a single line of code

 

Reading through the Doger 1.1 tutorial might be a good place to start as it covers building the list from back to front, opaque/transparent sprites, etc. etc., and basically how rapinit works to set up a load of things you don't have to think about again.

[+CyranoJ]

Yep, RAPTOR will do what it's told to do (via the rapinit.s file)

 

BASIC just pokes around with this list

[omf]

Also, if it is defined after the particle/text layer, and it is set to opaque then it will appear over the top and obscure the text behind it.

so the particle layer does the text?

that would be why i was having issues to a degree, i replaced this with the background object.

my thinking was why do i need particles do draw a picture and display some text

 

 

Reading through the Doger 1.1 tutorial might be a good place to start as it covers building the list from back to front, opaque/transparent sprites, etc. etc., and basically how rapinit works to set up a load of things you don't have to think about again.

ok ill look into the Doger example code and see if i can make some kind of sense of it any better.

 

i may try and tidy up invaders a little for practice later when I know what i'm doing

[+Sporadic]

 

ok ill look into the Doger example code and see if i can make some kind of sense of it any better.

 

i may try and tidy up invaders a little for practice later when I know what i'm doing

I highly recommend reading the tutorials on the website if you haven't already.

 

http://reboot.atari.org/new-reboot/rbplus/

[sh3-rg]

so the particle layer does the text?

that would be why i was having issues to a degree, i replaced this with the background object.

my thinking was why do i need particles do draw a picture and display some text

I think of that object as being like the screen display in old BASIC things from my past, all the PRINT, PLOT and, erm, particle effects lol, get spammed to that one area of memory this object uses for its bitmap. You can make multiple copies of this object or part of it by setting their gfx address to the same one or an offset into it, and also use g_wdith for narrower slices of it. You can reduce its size (within the usual limitations), hide it off the bottom of the screen until you need it, make it inactive, scale it, everything you can do with a normal object.

[omf]

ok i have done some reading and cobbled together what I intended to do so start with

 

just one little thing, from what CJ said about the layer being active or not and it will or will not be displayed: if I set it to active in the rapinit.s file it shows and not it is inactive (this also appears to deactivate the particle object too as i get a blank screen), but if I set it to active there in the rapinit.s file then set it to inactive with RSETOBJ it doesn't appear to do a great deal, I can move it out of the way and its fine, but this to me just seems a little weird to do. I would prefer to turn the screen off when I don't want it if you know what I mean

 

is this how it should be working? if it is and having various objects off the viewable screen is fine then that's fine, I will go with that

[sh3-rg]

Chrome and its fucking tab bollocks, lost my post twice, ffs

 

quickly: read tutorial zero from point "So what we're going to concentrate on first is" to get idea of how OP builds screen display/line buffer/line at a time stuff.

 

Objects in list start at 0.

 

Make variables for each object in project:

 

DIM textlayer% : textlayer=0

DIM background% : background=1

 

...

 

RSETOBJ(background,R_sprite_active,R_is_inactive) ' make background object inactive

 

...

 

There are a few issues with making the first and/or last objects in a list inactive, but that shouldn't be a concern until you are using multiple raptor lists.

 

You can't really "turn the screen off", but if you do quickly want to display nothingness you could always have a huge black opaque lump of nothing at the end of your list and make that active, or have a second list that's just a single object of nothingness.

[+Sporadic]

There are a few issues with making the first and/or last objects in a list inactive, but that shouldn't be a concern until you are using multiple raptor lists.

 

I have a feeling even with one list, making the first object inactive kills everything else.

 

Not tried it recently so don't quote me on that

[sh3-rg]

yeah, it's a funny one, I'm not 100% confident in how it works (or doesn't work!), that's why it might be better to set the first or last object yo y=255 or something similarly off screen instead of inactive. It's a crappy thing for someone just getting into it to come across, sorry about that OMF :/

[omf]

yeah, it's a funny one, I'm not 100% confident in how it works (or doesn't work!), that's why it might be better to set the first or last object yo y=255 or something similarly off screen instead of inactive. It's a crappy thing for someone just getting into it to come across, sorry about that OMF :/

 

its fine, life has many issues, i may as well add one to the list, LOL

[omf]

so what's the trick with making sprites then, I have spend quite a lot of time trying to get this right and the best I have managed to get it a garbled square

 

then i thought it might be keping something from the build folder so deleted it hoping that it would be re created, then when rebuilding it appears to work but then fails then looking in the created build folder does not contain the gfxdata and clut files that it should do, this is probably due to my broken sprite picture, however it looks ok in paint shop pro 7

 

source is attached

 

 

 

Reading assets.txt line
Processing ASSETS\GFX\wd.bmp
Converting BMP internally into gfxdata/clut...
File is 1142815 pixels wide, 16385 pixels high and is 65280 bits/pixel
Buildlink finished - everything went fine!

Assembling raptor skeleton...
build/ramassets.inc 2: Error: cannot open include binary file (build/wd.bmp.gfxdata)
build/ramassets.inc 4: Error: cannot open include binary file (build/wd.bmp.clut)
Build error!

test.rar

Edited August 29, 2015 by omf

[ggn]

File is 1142815 pixels wide, 16385 pixels high and is 65280 bits/pixel

 

 

Yeah that's probably a liiiitle bit off . FWIW I opened wd.bmp on paint shop pro 7, pressed "save as", save as type "windows or os/2 bitmap (*.bmp)", overwrote the file and then ran build - then everything built.

 

[EDIT]My guess is that you used a different file format to save the file. Did that happen?

Edited August 29, 2015 by ggn

[sh3-rg]

There were a few little things - the weird one with the gfx file I don't know about, that's wasn't a standard BMP AFAICT. Saved it back out with psp8 and it's OK.

 

Your sprites were 31x31 - there are strict sizes for object widths, I've changed the gfx and rapinit to 32x32s.

 

Objects in the list start at 0, so your objects were off by one - changed that, too.

 

You're off now, have fun! :0)

 

test.zip

 

EDIT: Oh, and the animation frame number - it's best to think of it as "amount of additional frames after this one" as it was set to 9 and should have been 8 for 8 more frames.

 

(slow it down and you'll also notice how animations work in reverse to what you might expect - the first frame is the last one in the graphic, one of the fun things you just get used to!)

Edited August 29, 2015 by sh3-rg

[omf]

 

Yeah that's probably a liiiitle bit off . FWIW I opened wd.bmp on paint shop pro 7, pressed "save as", save as type "windows or os/2 bitmap (*.bmp)", overwrote the file and then ran build - then everything built.

 

 

did the animation work for you? i have a garbled square again , it doesn't like me I don't think,

 

i was testing several things, that one may be caused by the os/2 option, im not sure

[omf]

There were a few little things - the weird one with the gfx file I don't know about, that's wasn't a standard BMP AFAICT. Saved it back out with psp8 and it's OK.

 

Your sprites were 31x31 - there are strict sizes for object widths, I've changed the gfx and rapinit to 32x32s.

 

Objects in the list start at 0, so your objects were off by one - changed that, too.

 

You're off now, have fun! :0)

 

test.zip

really, ok, thanks ill look into that after taking the cat to the vet

 

so what are the size restrictions, 32x32 is obviously one of them but what are the others?

 

thanks

[sh3-rg]

really, ok, thanks ill look into that after taking the cat to the vet

 

so what are the size restrictions, 32x32 is obviously one of them but what are the others?

 

thanks

 

There's no height restrictions (in practical terms at least :0) ) Widths depend on colour depth - it is documented somewhere. I usually stick to multiples of 16 for everything but 1-bit, there I use multiples of 64. 24bit would require you to put the Jaguar in 24bit mode via rapapp.s - never really tried, wouldn't know how to include gfx via assets.tst or care to as they'd burn memory for little gain. The fun for me is with 4bpp stuff and those 16 CLUT entry segments.

Edited August 29, 2015 by sh3-rg

[+CyranoJ]

so what are the size restrictions, 32x32 is obviously one of them but what are the others?

 

 

 

Read the RAPTOR API documentation. Skip all the 'how to use the calls' stuff (because rB+ does that for you) and soak up the background knowledge.

[omf]

 

 

Read the RAPTOR API documentation. Skip all the 'how to use the calls' stuff (because rB+ does that for you) and soak up the background knowledge.

will do

 

I will get something worth using at least out of the jag in the end!!!

 

after I decide how to go about move animate, don't move stop animating, ill contemplate this some more as my initial attempts at changing stuff with rsetobj went a bit pants lol