• Features Wishlist 5 1
Currently:  
« previous next »
Pages: 1 ... 228 229 [230] 231 232 233   Go Down

Author Topic: Features Wishlist  (Read 687304 times)

0 Members and 1 Guest are viewing this topic.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Features Wishlist
« Reply #3435 on: July 01, 2015, 11:55:29 am »
Okay, since you tackled the parser, I have this feature wish:

Allow a very simple set of variable types.

I imagine you must keep the variable names stored somewhere, so maybe a byte indicating the variable type, too? You wouldn't have to do things like associate correct routines, though. Like just because an var is flagged as 8.8 fixed point, doesn't mean that multiplication of such a var should be automatically the fixed point multiplication routine. The current system for that, where the developer specifies is fine (and I like it that way).

However, here is where it can come in really, really useful. Custom variable types could be allowed and associated with an axiom. So if I wanted to make an axiom for rational numbers, I could have it specify a rational var type of 32-bits (2 16-bit ints) and have specially made math routines for those vars.

This might need to wait for Axe 2.0, though :P
Logged

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3436 on: July 01, 2015, 12:23:07 pm »
Quote from: Xeda112358 on July 01, 2015, 11:55:29 am
Okay, since you tackled the parser, I have this feature wish:

Allow a very simple set of variable types.

I imagine you must keep the variable names stored somewhere, so maybe a byte indicating the variable type, too? You wouldn't have to do things like associate correct routines, though. Like just because an var is flagged as 8.8 fixed point, doesn't mean that multiplication of such a var should be automatically the fixed point multiplication routine. The current system for that, where the developer specifies is fine (and I like it that way).

However, here is where it can come in really, really useful. Custom variable types could be allowed and associated with an axiom. So if I wanted to make an axiom for rational numbers, I could have it specify a rational var type of 32-bits (2 16-bit ints) and have specially made math routines for those vars.

This might need to wait for Axe 2.0, though :P
I think @Runer112 thought of doing something like that, but hey, you have bean here longer then me so idk.
But the difficulty i see, is what will happen when you have a pointer, and the parser does not know where that pointer points, how will it ever figure out if it points to a float or a string? (It will only know if you have manually set the var like "Some string"->A, then it can figure out if A is a string or not)
Logged
-German Kuznetsov
The impossible chemical compound.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3437 on: July 01, 2015, 12:40:38 pm »
Types are definitely something I want eventually, but I think it's going to have to be an Axe 2.0 thing. Even if I could flag variables as different types in the compiler, values being 16 bits large and stored in the hl register is ingrained throughout the compiler.
Logged

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3438 on: July 07, 2015, 06:12:09 pm »
Can you add a return(x) command that will return x places up the stack? I know you can just do that with Asm(E1) (x times), but it might be something you might want to consider.
Edit: would it be possible to make it so that it returns up till a certain lbl in the stack, no matter how deep you are? (ex: main->engineStart->render, i call return(main) in the render method, it return to the point where main() called engineStart() )
« Last Edit: July 07, 2015, 06:20:06 pm by c4ooo »
Logged
-German Kuznetsov
The impossible chemical compound.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3439 on: July 07, 2015, 06:31:46 pm »
It's impossible to safely return by multiple levels at once because anything can be on the stack, not just return pointers. So the nth return pointer could be n stack entries deep, n+1 stack entries deep, or n+100 stack entries deep. It's also just pretty gross from a language design standpoint.

In cases like this, I think you should consider using return codes as signals, or a code reorganization to avoid the "need" for multi-level returns in the first place.
Logged

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Features Wishlist
« Reply #3440 on: July 11, 2015, 01:45:07 pm »
So, did you "only" optimize or did you change the way the compiler works ? And in any case, with your changes, does that make the addition of .org easier or not ?

And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.
Logged
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline pimathbrainiac

  • Occasionally I make projects
  • Members
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1731
  • Rating: +136/-23
  • dagaem
    • View Profile
Re: Features Wishlist
« Reply #3441 on: July 11, 2015, 01:47:50 pm »
Quote from: Hayleia on July 11, 2015, 01:45:07 pm
And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.

I second this request. I always have to make programs that take my program with the data and convert into an appvar when I'm working with raw data appvars.
Logged
I am Bach.

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3442 on: July 11, 2015, 02:17:45 pm »
Quote from: pimathbrainiac on July 11, 2015, 01:47:50 pm
Quote from: Hayleia on July 11, 2015, 01:45:07 pm
And could we also have the ability to compile as an appvar ? This would be very useful for people who make external levels, or external anything.

I second this request. I always have to make programs that take my program with the data and convert into an appvar when I'm working with raw data appvars.
+1 I usually just have another program to genarate the appvar. A possibility i see is that if a file has a special header (..NAME for example) that file file be genarate an appvar. So basicly you can do prgmDATA in your main program, and if DATA has a "..MYGAMEDATA" header, axe will genarate an appvar from the data in prgmDATA, while still compiling the other files normally.
Logged
-German Kuznetsov
The impossible chemical compound.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3443 on: October 27, 2015, 07:11:21 pm »
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)
Logged
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3444 on: October 27, 2015, 08:22:24 pm »
Quote from: E37 on October 27, 2015, 07:11:21 pm
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)

I've abstained from providing hook functionality for a few reasons. But the main reason is that hooks are simply too low level and too closely tied to the OS.

To operate meaningfully, most hooks need OS RAM and call equates, and there are far too many of these to add as built-ins to Axe. In a similar vein, there are many useful hooks. If one was added, then it would only feel right to add the others, and this would also clog up built-ins. And if only some things existed as built-ins to avoid clogging them up, then you'd probably end up turning to assembly to fill some gaps. In which case, you could reasonably just use assembly for all of it. And you can already implement hooks with a minimal amount of assembly that run Axe code for their main functionality.
Logged

Offline Geekboy1011

  • The Oneironaut
  • Donator
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2031
  • Rating: +119/-2
  • Dream that Awakening dream
    • View Profile
Re: Features Wishlist
« Reply #3445 on: October 30, 2015, 05:58:06 pm »
Quote from: Runer112 on October 27, 2015, 08:22:24 pm
Quote from: E37 on October 27, 2015, 07:11:21 pm
Do you think it would be possible to add keyhook functionality when compiled as an app?
getkeyH(key,key state) adding a state feature would let the app test for state like 2nd + mem.
It would be a really cool feature (assuming you aren't worried about people creating a bunch of memory protectors)

I've abstained from providing hook functionality for a few reasons. But the main reason is that hooks are simply too low level and too closely tied to the OS.

To operate meaningfully, most hooks need OS RAM and call equates, and there are far too many of these to add as built-ins to Axe. In a similar vein, there are many useful hooks. If one was added, then it would only feel right to add the others, and this would also clog up built-ins. And if only some things existed as built-ins to avoid clogging them up, then you'd probably end up turning to assembly to fill some gaps. In which case, you could reasonably just use assembly for all of it. And you can already implement hooks with a minimal amount of assembly that run Axe code for their main functionality.

Just to add a note to this. From my limited experiane with axe this is really what axioms accelerate at. Adding functionality that is out of scope for axe but would be really nice to have. Sadly yes you need to know asm for it, But it serves the purpose of setting/managing hooks far better then an internal setup.
Logged

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3446 on: November 03, 2015, 05:58:03 pm »
After ten minutes of searching (probably in all the wrong places) I can't seem to find a keyhook axiom.
Do you know of any good ones?
Logged
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3447 on: November 03, 2015, 07:13:42 pm »
Quote from: E37 on November 03, 2015, 05:58:03 pm
After ten minutes of searching (probably in all the wrong places) I can't seem to find a keyhook axiom.
Do you know of any good ones?

If such an Axiom existed, I would've suggested it in my earlier response. So if you wanted to create any hooks, you'd have to provide your own assembly backing for it.
Logged

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3448 on: December 08, 2015, 08:37:43 am »
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]
Logged
-German Kuznetsov
The impossible chemical compound.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +23/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3449 on: December 08, 2015, 03:14:23 pm »
For the 2nd options page one option should to have zoom compile as default.
(Although 1.3.0's compile time is awesome anyways)
Also compile to archive would be cool also.
(so I don't have to archive a program after I compile it)
The ability to see hidden programs' names correctly would also be nice.
(Having my program's name start with some random character can make it sort of hard to tell them apart)
Logged
I'm still around... kind of.
Pages: 1 ... 228 229 [230] 231 232 233   Go Up
« previous next »