Jump to content
IGNORED

RAPTOR Basic+ updates


ggn

Recommended Posts

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 by ggn
  • Like 3
Link to comment
Share on other sites

  • 1 month later...

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 by ggn
  • Like 5
Link to comment
Share on other sites

Following a topic here (well, to be honest I didn't pay attention too much to it apart from the title :P) 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 by ggn
  • Like 5
Link to comment
Share on other sites

Following a topic here (well, to be honest I didn't pay attention too much to it apart from the title :P) 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

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ggn
  • Like 4
Link to comment
Share on other sites

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)

  • Like 4
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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).

  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...

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!

  • Like 4
Link to comment
Share on other sites

  • 2 months later...

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 by ggn
  • Like 8
Link to comment
Share on other sites

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!

  • Like 5
Link to comment
Share on other sites

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 by ggn
  • Like 4
Link to comment
Share on other sites

  • 1 month later...

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.

  • Like 7
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!)

  • Like 5
Link to comment
Share on other sites

  • 1 year later...

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 :P). 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 by ggn
  • Like 5
Link to comment
Share on other sites

  • 11 months later...

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 by ggn
  • Like 8
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.

Guest
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.

Loading...
  • Recently Browsing   0 members

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