Language…
17 users online: 1337doom, AbuseFreakHacker, Beed28,  BeeKaay, ben15420, Doopu, Gorry, Green, LadiesMan217, Mecke1990, OrangeBronzeDaisy, Pink Gold Peach, playagmes169, rafaelfutbal, signature_steve, Skewer,  YouFailMe - Guests: 285 - Bots: 370
Users: 64,795 (2,370 active)
Latest user: mathew

Asar: Under new management

Originally posted by randomdude999
print double() seems to be a bit broken, for now just use dec() and hex().
Code
math round off
print dec(round(3/2, 0))


Rounds 1.5 to 0.

Originally posted by RPG Hacker
Code
math round off
print double(round(100/3, 0), 5)


Originally posted by error
error: Malformed function call. [print double(round(100/3,0),5)]


I'll wait till asar gets those fixed.
Give thanks to RPG hacker for working on Asar.
What version are you using? For me (i tried both 1.50 and the current master), "print dec(round(3/2, 0))" with "math round off" prints 2.
Originally posted by GreenHammerBro
Originally posted by error
error: Malformed function call. [print double(round(100/3,0),5)]


I'll wait till asar gets those fixed.


To my defense: I'm an idiot! :O
For some reason, I thought making the double() function only read to the first comma/the first closing parenthesis was fine. This means that both versions of the function are currently broken.

Will have to rewrite the function and do it properly this time (I'm assuming it should be possible to just let the math parser figure out where the second argument begins).

As for why the first example results in 0... I have no idea. It really shouldn't. Is that the actual code you used? Is it the only code in your test file? I'll try to reproduce it later.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I test the actual code they sent me. It only have these code and nothing else.
Give thanks to RPG hacker for working on Asar.
Originally posted by Asar
Enter patch name: "C:\Users\GreenHammerBro\Desktop\smw romhacking\General Tools\asar beta\test.asm"
Enter ROM name: "C:\Users\GreenHammerBro\Desktop\smw romhacking\General Tools\asar beta\Copy of Super Mario World.smc"
2
Assembling completed without problems.
Press any key to continue . . .


Didn't print a 0.
Give thanks to RPG hacker for working on Asar.
So either you were using a different version (I think you never stated which version you used), or the code you quoted wasn't the code you originally tested. It's the exact same code as in that ASM file.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I did test that code and asar version from that post, not the one I made myself, 100% from that post.
Give thanks to RPG hacker for working on Asar.
What did you mean by "rounds 1.5 to 0" then? 1.5 should be rounded up to 2, so the round function is working fine (and your massive macro function you posted in the ASM library thread is useless).
Nevermind, I got it working for my player health patch.
Give thanks to RPG hacker for working on Asar.
Is it possible have an option to suppress the "it would be wise to set the 008000 bit of this address" warnings? I know they're harmless and they don't prevent the code from assembling, but I just think it would be nice to have an option so they don't appear on the command line output.

I'm writing a small homebrew project and I'm using something like this to define RAM addresses:
Code
org $7E0000                             ;
Temp:              skip 16              ; Temporary RAM, from $00-$0F
Joy1_Held:         skip 2               ; Held buttons on joypad #1
Joy1_Pressed:      skip 2               ; Pressed buttons on joypad #1
Selected_Color:    skip 1               ; Selected color (0, 1, 2) = (R, G, B)
Color_R:           skip 1               ; Red value for the color (0-255)
Color_G:           skip 1               ; Green value for the color (0-255)
Color_B:           skip 1               ; Blue value for the color (0-255)
Output_Color:      skip 2               ; Converted RGB color in SNES format


The reason I'm doing it like this is beacause I'm more fond of writing "LDA Color_R" instead of "LDA !Color_R". And also, I'd like to use RAM defines (not labels like above) specifically for naming the "Temp" variables, like so:

Code
!Named_Var  = Temp
!Named_Var2 = Temp+2
SomeRoutine:
  ; do something with Temp (!Named_Var) and Temp+2 (!Named_Var2)

undef "Named_Var"
undef "Named_Var2"

I'm reverse-engineering and hacking F-Zero (SNES)!

My YouTube channel, with various hacking tests
That doesn't map to ROM. I'm surprised it doesn't error out.

Solution: Use 'base $7E0000' instead.
<blm> zsnes users are the flatearthers of emulation
Actually, there's an even simpler solution. You added it yourself, but it's so rarely used that you probably forgot about it (it's listed in the manual, though).

Code
RAMAddressLabel = $7E0000


This is a well-defined operation in Asar and adds a label "RAMAddressLabel" with an address of $7E0000.

EDIT:
It also seems to support math, I just tested it since I wasn't sure. So something like this

Code
AnotherLabel = $7E0000+16


Is possible. The only thing that's not supported is setting one label to another label. So this right here

Code
Label1 = $7E0000
Label2 = Label1+16


will throw an error, so if you want something like that, base might still be the better solution.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
It's not that I forgot about that one, it's that it's not simpler.

Yes, for a single label, that one is easier. But when there's multiple like this, either you go 'Joy1_Pressed = $7E0012' and hope you won't need to rearrange them, or you use 'Joy1_Pressed = Joy1_Held+2' and repeat a bunch of labels (and unless you changed it, you can't even set labels to each other).

Perhaps those structs p4 added would work, not sure. I never figured out what exactly they do.
<blm> zsnes users are the flatearthers of emulation
Let me rephrase that statement: it's the more intuitive solution. I suppose whether it's the simpler solution depends what it's used for. When assigning just a single or very few labels, and especially when their position matters and/or is well-known, I'd say that direct assignment is slightly simpler. Admittedly the base solution probably makes more sense here, since it's for a homebrew and thus CatadorDeLatas probably just wants to use whatever memory is availble and positioning doesn't matter. base is inded the better solution for this, as it prevents fragmentation and makes it easy to move labels around.

Originally posted by Alcaro
or you use 'Joy1_Pressed = Joy1_Held+2' and repeat a bunch of labels (and unless you changed it, you can't even set labels to each other).


Didn't change it, no, although I suppose it would be technically possible for at least this type of label. Haven't tried it yet or looked too deeply into it, but in theory it should be possible to let Asar memorize which labels are well-defined (bascially just labels which were directly assigned) and then make it legal to use well-defined labels in math while only erroring on non-well-defined labels. Could be a nice-to-have feature, but likely a rarely used one.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Code
a = b
b = a+1

There, now they're both directly assigned.

Better require the source(s) to be defined before the target as well.

But requiring direct assignments is indeed a good idea, otherwise I'm sure SOME damn moron would go 'label = anotherlabel<<16' and trigger the labels-moving-around internal error... ...and I hope org Label<<16 and base Label<<16 are similarly restricted...
<blm> zsnes users are the flatearthers of emulation
If you're using this as some kind of shared file, might be a good idea to use pushpc and pullpc so that the pc doesn't get reset whenever including this file.

EDIT: And maybe also pushbase and pullbase, which is new to Asar 1.60.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Just gonna go ahead and and drop a first Asar 1.60 beta release here. Didn't really discuss this with anyone (although I suggested a dicussion after we were done with the v1.60 milestone list), but since it's really just a beta release and not the full thing, I thought it should be okay to just do this without a lot of discussion taking place.

My main reasons for wanting to do a beta release before the actual release this time: v1.60 is full of changes. It probably has the most changes out of any Asar versions so far. Many of them are also quite severe and change a lot of code under the hood. Since I want to make sure we didn't break compatibility of any patches, sprites etc., I thought a beta release would be a good idea (note that there are minor incompatibilities in command line parameters, since I slightly changed their format. Also the DLL isn't binary compatible with older versions, but should still be code-compatible, I think). So we would appreciate it if many people could try out this beta to see if they find any incompatibilities or other problems. Another reason for this beta is that I want to see which executable works for the most people. Some people said they had problems running v1.40 and v1.50 of Asar, which I had built in MSVC, so I wanted to try different builds to figure out which one works for most people. Included are asar-v140.exe, which is built in MSVC2015's default platform toolset, asar-v140_xp.exe, which is built in MSVC2015's compatibility platform toolset (I think this is also what I used for v1.50), and asar-gcc.exe, which was built in MinGW (this should be closest to Alcaro's origional releases). I would love for people to try out all three executables and tell me which ones work for them.

Please note that things between this beta release and the eventual full release of v1.60 can (and likely will) still change. This beta doesn't necessarily contain all features that are going to be in the full v1.60 yet, nor will all features necessarily stay the same. I don't expect changes between this and a full release to be major, though, so if you write code using this version of Asar, it should hopefully just work with the full release as well or, at most, require minor adjustments. Nevertheless, keep this in mind. (It is not recommended to submit resources yet using this beta)

As for changes in this version, I'm not going to recite all of them here since the changelog is gigantic this time around. Instead, I will just link to the new online changelog, which contains the full list of changes.

Most of the more notable changes should be useful mainly for tools hosted on here. We've added support for include search paths, which should be pretty handy in tools since it should make finding ASM files in specific folders more simple and reliable. I know that I've struggled with this problem with a bunch of tools hosted here. When using them in certain situations or from certain locations, they just stopped working or threw error messages for not finding certain files. Making use of include search paths in those tools, when done right, should make this problem disappear.

We've also added support for standard defines and standard include search paths to Asar. In theory, this should allow creating just a single shared library of code to easily be used across all different tools hosted here by creating a ZIP file with contents that can just be unzipped into the Asar directory. If people decide to make use of this, that should make it possible for all tools to eventually start using the same shared code instead of a new implementation for every different tool.

We also added a better way of handling macro labels (there are now macro sub labels, macro +/- labels etc.), as well as a workaround for those tools that want to include sub routines inside macros, since that caused problems for some people (the labels inside the macros started new sub label groups). Labels can now be declared without starting new sub label groups (although those macros still seem quite hacky to me).

There's way, way more stuff in this new version and I couldn't even possible remember everything of that myself, so if you care about all of the changes, make sure to read the changelog.

Note that the ZIP file doesn't contain the Asar source code anymore and instead just links to GitHub now, where the source code is hosted. That made the most sense to me.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
We didn't change the major API version, so the DLL should still be compatible (assuming, of course, that the DLL you are replacing is version 1.50, 1.40 and earlier use an old API version). This means you should be able to just drag-and-drop the new DLL to replace the old one.