• Features Wishlist 5 1
Currently:  

Author Topic: Features Wishlist  (Read 253526 times)

0 Members and 1 Guest are viewing this topic.

Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55816
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • CodeWalrus
Re: Features Wishlist
« Reply #660 on: May 27, 2010, 01:28:16 pm »
If you don't use the editor, would that require you completly code an entire BASIC code (well... Axe) viewer like Builderboy did? If so, then I guess it might be best to disregard the instant goto feature or wait completly at the end of development before attempting at adding it (to make sure you have enough space left, assuming such thing would take a considerable amount of memory in the APP)
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Features Wishlist
« Reply #661 on: May 27, 2010, 05:28:57 pm »
I managed to come up with a feature request. The sprite routines seem somewhat incomplete, only including OR, XOR, and full clear followed by OR (Pt-On, Pt-Change, and Pt-Off, respectively).
My two suggestions are:
add something corresponding to AND, or add a command to use two layers specifying what is cleared followed by what is OR'd
The second, though somewhat less useful one is: Allow sprite commands (except for Pt-Change) to have an extra argument (not required) that would save what's about to be written over. Basically creates a back-copy for later restoration, presumably when the other sprite moves.
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.

Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55816
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • CodeWalrus
Re: Features Wishlist
« Reply #662 on: May 27, 2010, 11:15:53 pm »
AND would be nice for sprite masking.


For the second one, do you mean so we don't have to redraw the entire screen (or everything surrounding moving sprites) when stuff moves and instead we just redisplay what was behind the sprite? It sounds like it could be a nice feature.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Features Wishlist
« Reply #663 on: May 27, 2010, 11:55:00 pm »
That's what backbuffers are for so you don't have to save it every time you draw the sprite.

The AND thing I guess I can see how it would be used... but then you have to use AND followed by an OR to actually get masking.  That's the same amount of steps as doing an OR followed by an XOR (another way of doing masking) so it doesn't really add anything new, just more convenience.  Also, I'm all out of tokens for that.

Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.

« Last Edit: May 27, 2010, 11:55:35 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Art_of_camelot

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6171
  • Rating: +191/-9
  • YouTube channel has my solo work and collaboration
    • View Profile
    • My YouTube page!
Re: Features Wishlist
« Reply #664 on: May 27, 2010, 11:58:50 pm »
Sounds great! Go for it! =D

Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55816
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • CodeWalrus
Re: Features Wishlist
« Reply #665 on: May 28, 2010, 12:09:46 am »
That's what backbuffers are for so you don't have to save it every time you draw the sprite.
My concern was more about grayscale. Where on the backbuffer and buffer do you store the area your sprite is gonna walk on to redraw it later after the sprite moved, since both buffer and back buffer are entirely used for the grayscale?

That said it is not a big hurry, though. Seeing how fast

Quote
Coming Soon:
I'm thinking of having a "command freeze" very soon.  I'm a little overwhelmed right now with fixing the stuff I already have and I think I want to start working more on the parser itself to make it more efficient and add all those cool features like app compiling, error scrolling, long names for labels/static pointers, making the syntax more loose, many more optimizations, safety modes, on breaks; you get the point, the list goes on for a while and these are things I've been avoiding becasue I wanted to make the parser more functional first.  Right now, I think its pretty decent, so its time I start working on those other features until I get a good chunk of them done.  There might still be some new commands, but not very many between updates.  These will be the 0.3.x updates.
Sounds like a good deal. I think it's better to improve the parsing and stuff before adding too many other features, so that makes less features code to change later once you optimize. Also, this would make it less overhelming for people who will participate in the programming contest. Since the contest will most likely only last 3 and half a month (or 4), not having to change our code syntax everytime an Axe update comes out will be very appreciated. (people could just use an old Axe version if they don't want to update their code, but that slows down their development considerably)

Also seeing how much you worked on this despite school and stuff, I think if you want to take a break at one point, you deserve it a lot. :)
« Last Edit: May 28, 2010, 12:12:15 am by DJ Omnimaga »
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

_player1537

  • Guest
Re: Features Wishlist
« Reply #666 on: May 28, 2010, 12:04:45 pm »
yay, this sounds nice I can't wait for app compiling and on-breaks (which I hope will include interupts in general)

666th post in this thread >:D

Offline calcdude84se

  • Needs Motivation
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2272
  • Rating: +78/-13
  • Wondering where their free time went...
    • View Profile
Re: Features Wishlist
« Reply #667 on: May 31, 2010, 09:16:51 pm »
true, though it's more troublesome for greyscale, as DJ said. OR followed by XOR? Hmm... never realized that. Will use.
Yeah, the command freeze is a good idea. And as always, keep up the good work!
"People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster."
-Adam Osborne
Spoiler For "PartesOS links":
I'll put it online when it does something.

Offline nemo

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1203
  • Rating: +94/-11
    • View Profile
Re: Features Wishlist
« Reply #668 on: June 03, 2010, 04:01:23 pm »
will there ever be a way to invert all 64 pixels of a sprite? like if i had a white 8x8 sprite with a black border, and i wanted to change it into a black sprite with a white border, will that be implemented? i know i can use two for( loops to do it with pxl-change(, but i'm wondering if it may be implemented in the future


_player1537

  • Guest
Re: Features Wishlist
« Reply #669 on: June 03, 2010, 04:07:56 pm »
you can also do "pt-change(x,y,pic22)" with pic22 being [FFFFFFFFFFFFFFFF]  You don't have to use pic22, just an example.  I believe our dear friend made a routine that does this with out using another sprite, but it goes along the same lines of two for( loops...only different

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Features Wishlist
« Reply #670 on: June 03, 2010, 05:58:44 pm »
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2896
  • Rating: +467/-17
    • View Profile
    • TI-Boy CE
Re: Features Wishlist
« Reply #671 on: June 03, 2010, 06:01:01 pm »
If you want to actualy change the sprite data itself, you could run this:

Code: [Select]
For(F,0,15
{Pic0+F} xor 255->{Pic0+F}
End

and then the sprite will stay inverted forever after.
Just remember that will only work as expected for no-stub programs. If it's for a shell, the sprite will be inverted every other time you run the program, and for an App the sprite wouldn't invert at all.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline DJ Omnimaga

  • Now active at https://codewalr.us
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55816
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • CodeWalrus
Re: Features Wishlist
« Reply #672 on: June 03, 2010, 06:45:00 pm »
wow didn't knew we could use this. x.x
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF


Bandcamp|Reverbnation|Facebook|Youtube|Twitter

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #673 on: June 07, 2010, 12:41:30 am »
The following is a list of all screen/buffer commands, with the size of the routine indicated in parentheses:
  • ClrHome (6)
  • ClrDraw (3)
  • ClrDrawʳ (6)
  • DispGraph (46)
  • DispGraphʳ (63)
  • StoreGDB  (6)
  • StorePic  (11)
  • RecallPic  (11)
  • DrawInv  (17)
  • DrawInv ʳ (20)
  • Horizontal + (18)
  • Horizontal - (18)
  • Vertical + (13)
  • Vertical - (13)
  • Shade() (8)

The following is a list of the screen/buffer commands that do not utilize subroutines and the increase therefore in program size if the command is called 1, 2, 3, or n times compared to if it was called using subroutines:
  • ClrHome (-4, -1, 2, 3n-7)
  • ClrDraw (-4, -4, -4, -4)
  • ClrDrawʳ (-4, -1, 2, 3n-7)
  • StoreGDB  (-4, -1, 2, 3n-7)
  • StorePic  (-4, 4, 12, 8n-12)
  • RecallPic  (-4, 4, 12, 8n-12)
  • Shade() (-4, 1, 6, 5n-9)

Perhaps you could add an optimization feature that counts the number of references to commands such as these? This would either include the routine inline or in a subroutine that is called multiple times depending upon which method is more size efficient based on the number of times the routine is called.
« Last Edit: June 07, 2010, 12:47:37 am by Runer112 »

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Features Wishlist
« Reply #674 on: June 07, 2010, 12:47:03 am »
That's actually much more tricky than it sounds.  First of all, I would have to make another pass through the program at the beginning and its not just a matter of counting the tokens.  I have to make sure I'm not including strings, token values, and other uses that don't actually count as code.  I will optimize this eventually once I get long name labels.  The two are kind of related even though they sound like different features.

However, in the mean time, you are free to put them in subroutines yourself if you're trying to save space.

Lbl SP
StorePic
Return
___Axe_Parser___
Today the calculator, tomorrow the world!