RAPTOR Basic+ updates

[ggn]

MOAR POWA!!!1111

New commands:

powabset(spr_index, offset, no_of_times, array_of_values, skip_offset)
powabdiff(spr_index, offset, no_of_times, array_of_values, skip_offset)
powabzap(spr_index, offset, no_of_times, value, skip_offset)

Exactly the same as powaset, powadiff, powazap but you can control the offset to skip to the next object (it's hardcoded to 188 for the other three). So a skip_offset of 188 will make a powabset equivalent to powaset, but 188*2 will update every other object. 188*3 will update one object in 3. -188 will go backwards.

 

In hindsight I should have probably updated powaset/diff/zap with these 3 but I like the comedy names, so let's just leave them all in .

Edited August 29, 2015 by ggn

[ggn]

Well the following changelog will probably please a lot of people. It has been frequently asked for but nobody presented me a real world need for it. Until now...


- Assets can now be packed. Suffix field C with "_pack" in assets.txt
- New command added: powaunpack(source_address, destination_address) will unpack data from source_address to destination_address. Note that it's your responsibility to reserve enough RAM for unpacking. Also, no checking to see if a packed asset exists at the source address - again it's your responsibility!
- Small fix for buildlink with monochrome bmps less than 32 pixels wide.

 

A quick test I made showed that it takes about 3 seconds to unpack a 800k asset so it's not tooooooo bad. Now let's see what you can do with all these tons of RAM saved .

Edited October 4, 2015 by ggn

[sh3-rg]

Thanks, GGN! Another awesome add!

[ggn]

Following a topic here (well, to be honest I didn't pay attention too much to it apart from the title ) I present you:

 

rbsort(table,no_of_indices) will sort an array of longwords from smallest to largest. Only longwords (4 byte integers) for now.

Also, changed the build error behaviour: now the error log is written to the console instead of opening notepad (what was I thinking?).

Fixed a bug in BUILD.bat that would continue the build process in abs mode if linking failed.

 

Have "fun" with it.

 

(P.S. the whole thing took about 10 minutes, finding the source, including it, exposing it to rb+, writing the example program and running it - worked 1st try!)

Edited October 7, 2015 by ggn

[omf]

Following a topic here (well, to be honest I didn't pay attention too much to it apart from the title ) I present you:

 

rbsort(table,no_of_indices) will sort an array of longwords from smallest to largest. Only longwords (4 byte integers) for now.

Also, changed the build error behaviour: now the error log is written to the console instead of opening notepad (what was I thinking?).

Fixed a bug in BUILD.bat that would continue the build process in abs mode if linking failed.

 

Have "fun" with it.

 

(P.S. the whole thing took about 10 minutes, finding the source, including it, exposing it to rb+, writing the example program and running it - worked 1st try!)

any chance of an ascending or descending option for this ?

 

i don't think you updated the build batch file to include your fix in github commit either it says 2 days ago for the file time

same with the example program

although, this is a good enough example:

basic_r_size=0
basic_r_indx=0

dim I as integer
dim a[9] as integer

SET A[9]
1, 9, 7, 3, 4, 6, 5, 8, 2
END SET

rbsort (A, 9)

FOR I = 0 TO 8
rlocate 0, (10*I)
PRINT A[I]
NEXT I

[Sporadic]

 

any chance of an ascending or descending option for this ?

 

i don't think you updated the build batch file to include your fix in github commit either it says 2 days ago for the file time

same with the example program

although, this is a good enough example:

basic_r_size=0
basic_r_indx=0

dim I as integer
dim a[9] as integer

SET A[9]
1, 9, 7, 3, 4, 6, 5, 8, 2
END SET

rbsort (A, 9)

FOR I = 0 TO 8
rlocate 0, (10*I)
PRINT A[I]
NEXT I

FOR I = 8 TO 0 wouldn't that work? Just iterate the other way

[omf]

yes that would work too i guess

[ggn]

i don't think you updated the build batch file to include your fix in github commit either it says 2 days ago for the file time

That would be commits https://github.com/ggnkua/bcx-basic-Jaguar/commit/ac9cb66823094584db6b837ff84cb77030b2ec79and https://github.com/ggnkua/bcx-basic-Jaguar/commit/5097dd357719070e5484dbacbf9ce57fbb5105e5.

 

same with the example program

To be honest making an example for a sort routine is so trivial that I didn't think I'd need to commit a whole project for it.

[ggn]

More silly things!

 

- Introduced an alternative to rsetobj/rgetobj: users can now do rlist[object].index=value instead of rsetobj and myval=rlist[object].index instead of rgetobj. They are both faster in execution too.
- Updated nyandodge to demonstrate the new feature.

This update might seem insignificant but in my opinion is pretty nice because I never did like those rset/rgetobj instructions. I think the new syntax is better! To use it, you need to add the following line to your .bas listing, preferably at the top of the file:

 

rlist=(RAPTOR_LIST *)strptr(RAPTOR_sprite_table)

(yup, a new dependency. I suck. But.... patches welcome!)

 

To use rlist you need to replace index with the types below, which are directly mappable to R_sprite_* constants:

 

obj
active
x
y
xadd
yadd
flip
width
height
vbox
hbox
gfxbase
framesz
framedel
curframe
maxframe
animloop
wrap
timer
track
colchk
scaled
scale_x
scale_y
CLUT
animspd
bytewid
tracktop
was_hit
coffx
coffy
remhit
bboxlink
hitpoint
damage
flash
gwidth
rmotion
rmcurfrm
rmfrm
userdat1
userdat2
userdat3
userdat4
userdat5
userdat6
userdat7

 

 

So instead of rsetobj(object,R_sprite_x,value) you now can do rlist[object].x=value, which I think is much better! (not to mention it executes faster internally!)

 

And that's all I guess. Enjoy!

 

[EDIT] Seems some people missed my warning above, so I made it a bit more obvious!

Edited October 16, 2015 by ggn

[Sporadic]

Interesting change, cheers!

[ggn]

Right, so a few commits later we have a small fix for a problem happening when importing generic asset files into rb+. Just update to latest version and you will never see this happening (if you haven't already but I've never seen it mentioned before)!

 

Many thanks to Sporadic for being the Guinea pig for this fix! (also the reporter - so it was only fair ).

 

 

 

(I think it's time for a new installer too since many things were added lately. I'll check with CJ because he wants to port over a feature he added to Rebooteroids recently and we'll see)

[ggn]

Print? Who uses print? In basic????

 

Anyway, long standing and embarrassing bug finally fixed:essentially basic_r_size and basic_r_indx were swapped. Many thanks to OMF for the fix, and it is now available!

[Sporadic]

Print? Who uses print? In basic????

 

Anyway, long standing and embarrassing bug finally fixed:essentially basic_r_size and basic_r_indx were swapped. Many thanks to OMF for the fix, and it is now available!

 

Lmao, I thought the names were wierd. Didn't think much of it till now

[ggn]

After some back and forth with OMF I now committed a new example (called "pack") that that demonstrates how packing and unpacking resources works. Thanks to OMF for this!

 

(it might sound trivial but the syntax isn't the easiest to remember so at least now there's a reference).

[ggn]

Here's a new update which will possibly help people: Buildlink will now delete the cached files in the build folder if assets.txt is newer than any single generated file. Hopefully this will take care of old or wrongly produced cached files. This means that if you were messing around with assets.txt and changed some definition (for example, changed the bit depth, or if you want a graphic's clut or you changed raw samples to ulaw) then the cached build files will automatically be deleted forcing a rebuild. I probably lost count of the times I've suggested "delete your build folder and try again" so maybe this will help a bit!

[ggn]

Well, with all the things that happened around Christmas I totally forgot to post an update here! So here it is, late but not forgotten:

Raptor BASIC+ v1.3

Lots of bug fixes and new features that enable you to create more cool stuff! So here's the main changes:

- New command powablitlist(pointer_to_blitlist). pointer_to_blitlist contains an array of ints that have a1_base,a1_flags,a1_pixel,a2_base,a2_pixel,a2_flags,b_count,b_patd,b_cmd.
- New raptor variable exposed: raptor_blitter_use controls blitter usage in raptor (internally). 0=auto, 1=force blitter, 2=blitter disable
- Added WORD, BYTE, UWORD, UBYTE types (use caps to access them for now)
- Introduced an alternative to rsetobj/rgetobj: users can now do rlist[object].index=value instead of rsetobj and myval=rlist[object].index which is faster in execution too.
- New function: rbsort(table,no_of_indices) will sort an array of longwords from smallest to largest. Only longwords (4 byte integers) for now.
- Added a quick reference guide (incomplete).
- Assets can now be packed. Suffix field C with "_pack" in assets.txt
- New command powaunpack(source_address,destination_address) will unpack data from source_address to destination_address. Note that it's your responsibility to reserve enough RAM for unpacking. Also, no checking to see if a packed asset exists at the source address - again it's your responsibility!
- New commands:
powaset(spr_index, offset, no_of_times, array_of_values)
powadiff(spr_index, offset, no_of_times, array_of_values)
powazap(spr_index, offset, no_of_times, value) will write value no_of_times times in offset offset, starting with index spr_index.
powabset(spr_index, offset, no_of_times, array_of_values, skip_offset)
powabdiff(spr_index, offset, no_of_times, array_of_values, skip_offset)
powabzap(spr_index, offset, no_of_times, value, skip_offset)
Exactly the same as powaset, powadiff, powazap but you can control the offset to skip to the next object (it's hardcoded to 188 for the other three)

Grab the installer from the usual places or use git to stay at the bleeding edge of the development. As usual, have fun!

Edited January 13, 2016 by ggn

[ggn]

After some brainstorming today (although the brain part can be argued ) I discovered that bcx can write comments on the generated C code to help people track syntax errors easier. So I turned this on by default (before you needed to use a command for this), so just update to the latest bc.exe and enjoy!

[ggn]

Just pushed a new feature: current raptor.o has support for user saved data, so the definition of array raptor_highscores_hex has been extended for this purpose. So you have 96 integers (indices 31 to 127 inclusive) to store any settings apart from scores. DO NOT use indices 0-30 as they are used by raptor internally!

 

Also, project scores has been updated to demonstrate this.

Edited January 14, 2016 by ggn

[ggn]

Here's one that took a bit of persuasion to run properly:

 

 

New function: powaeeprom(readwrite, buffer) will read from the EEPROM to the address that buffer points if readwrite is 1 and will write to the EEPROM if readwrite is 0.

 

 

You can check out project scores, it's updated to work for both MT and EEPROM. Note that the EEPROM can only store 128 bytes so if you choose to have raptor manage the high scores then there is only room for scores and names - user defined data (as mentioned in previous post) will NOT be written! In case that you want to write scores and user data you have to roll your own.

[+Gemintronic]

Here's one that took a bit of persuasion to run properly:

 

 

New function: powaeeprom(readwrite, buffer) will read from the EEPROM to the address that buffer points if readwrite is 1 and will write to the EEPROM if readwrite is 0.

 

 

You can check out project scores, it's updated to work for both MT and EEPROM. Note that the EEPROM can only store 128 bytes so if you choose to have raptor manage the high scores then there is only room for scores and names - user defined data (as mentioned in previous post) will NOT be written! In case that you want to write scores and user data you have to roll your own.

 

Is this eeprom built into the Jag or is it on some sort of sexy Reboot designed carts?

[GroovyBee]

 

Is this eeprom built into the Jag or is it on some sort of sexy Reboot designed carts?

 

Its available on both the BITD games and the jagware PCB and is optional if you use the blank BITD cart PCBs (depending on if the game supports it).

[ggn]

The good thing is that if your cartridge has the EEPROM installed you can just call this function and the data will be saved if present. So, like the Memory Track, it really is fire and forget

 

(also I know that most people just took the code from the scores example and butchered it to their needs!)

[ggn]

No updates for more than 1 year here - yay!

 

If anyone is following the project on github/bitbucket already knows that there have been some minor updates/fixes over the year but nothing very major. But a few minutes ago I committed a new feature that is interesting and will probably help newcomers and not (I wouldn't know, I hardly use the language myself ). So without further ado:

 

New rlist members: x_, y_, xadd_, yadd_. These let the programmer access the integer part of the coordinates, so shifting left by 16 is not necessary. Project nyandodge updated to demonstrate this.

 

So let's look briefly at the implications of these additions.

• If you do something like

  
  rlist[my_object_no].x=(5<<16)+(65536/2)    'fractional part is 65536/2=0.5*65536=$8000
  

  then your object's x coordinate will be set to 5.5. (the fractional part is kept internally by raptor as there are no fractional screen coordinates of course!). This was the only option up till now.
• If you now do something like

  
  rlist[my_object_no].y_=5
  

  then your object's y integer coordinate will be set to 5.
• One implication that's not apparent by point 2 at first sight is that the fractional part will not get updated! Initially the fractional parts of the coordinates are what you set it on your rapinit.s lists (or your program startup), so it's probably set to 0. But if you set it to something other than 0 then the fraction will remain unchanged! So, if you do something like

  
  rlist[my_object_no].x=(5<<16)+(65536/3)
  rlist[my_object_no].x_=10
  

  then your object's x coordinate will be 10.3! If you do wanted to set the x coordinate to 10 you'll have to use the .x field.

And that's it more or less. In terms of performance using the _ fields will be slightly faster than their full-blown counterparts. So if you use them heavily inside your code and don't care about fractions you'll get a nice little performance boost.

 

Anyway, that's that. Be careful with it but hopefully I hope it helps!

Edited February 26, 2017 by ggn

[ggn]

An update in under 1 year - oh snap!

So what is one supposed to do when one has a stable(ish) software which isn't widely much used (which means care factor to the author=low), relies on closed source libraries, has been broken way too many times from library updates (with emergency firefighting sessions to fix everything), and someone sends the author yet another black box update?

 

I suppose most people reading this probably answered "don't touch it" or "reject everything for the sake of stability and fear of regressions". And that's fine I guess, that's how I almost reacted when I got sent a said update. Actually my knee-jerk reaction was to reply "prove to me that it works 100%, try all sample projects, then get all people using rb+ to try the change and report back with success and only then I'll implement it". But I didn't do that either. Frankly I was really puzzled about how to handle this.

 

Then, other and more interesting stuff came along and this was shelved for many days. At one point I thought of a good compromise on how to solve the above problems but again put it aside as I'm not that enthusiastic about the project anymore and I'll take stability over new features any day.

 

Long story short, I remembered about this 1 hour ago and set about implementing the feature. It worked first time, at least with one example I tried.

 

(okay, I suppose this introduction dragged on for too long, so let's cut to the chase)

 

Well, that came out really wrong. It all boiled down to: I delayed applying this because a) I was afraid it would break compatibility if I replaced the original unpacking method, b) When I figured out how to apply it without breaking anything it still took a long while because rb+ is low priority for me. So just disregard the above! (left there for historic purposes - I'm not afraid to own up if I make a mistake and I won't wipe my posts just so I look good!)

 

The build system now accepts a new switch called FASTDEPACK. If you invoke this while building a ROM then a new GPU depack routine will be used which leads to faster startup times while booting. If the switch is not used then the old (but 100% robust) routine will be used instead. For example:

build myproject ROM FASTDEPACK

Which brings us to the disclaimer part: Consider the feature experimental for now! While I'm pretty sure it won't wipe your hard drive it might have bizarre side effects on your ROMs!.

 

Of course any feedback about it is welcome: Does it work for you? Does it not work for you? Is the old depack working ok? Is that broken? You are welcome to download the latest version and try it out!

 

Also, thanks to the person sending me the update in the first place .

Edited February 8, 2018 by ggn

[+CyranoJ]

Also, thanks to the person sending me the update in the first place .

 

You're welcome.