This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - adrusi
16
« on: May 25, 2013, 08:06:48 pm »
Quick update which adds support for archived pictures.
17
« on: May 25, 2013, 08:05:53 pm »
I have an update. This update fixes all the bugs listed above, makes redrawing the screen about three times faster, and adds support for archived picture files. The utility is actually usable now 
18
« on: May 24, 2013, 01:26:34 pm »
After I modified Ikkerens's sprite creator/editor[1], I figured it would be nice to actually be able to view the sprites together rather than just one at a time. This program lets you essentially create a rearranged spritesheet on the screen so that you can see how the individual sprites fit together. When it redraws the entire screen, it's a bit slow. The redraw takes almost a full second on my 84+SE, however, it doesn't do full redraws often. Interface: There are no on-screen interface elements, since the entire screen is used for displaying sprites. While F5 is down, it will display the original sprite sheet so that you can see how to navigate to the sprite you want. It redraws the screen when released. While F4 is down, it will display only the currently selected sprite. This lets you know which sprite is selected. It redraws the screen when released. Use the arrows to move the cursor. Every time the cursor moves, it simulates pressing F4, so the screen is redrawn. + and - will increment and decrement the x value of the sprite displayed in the selected square. This only redraws the relevant square. * and / will do the same the the y value. I've attached just the source, since it's mainly and axe utility anyway, so it's kind of useless on a device without axe. Bugs (will be fixed): - cannot change the sprite associated with squares lower than the first row
- cannot use sprites with an index in the spritesheet greater than 32
- moving the cursor left when cursor_x = 0 sets cursor_x = 3
[1]
http://ourl.ca/18969#quickreply
19
« on: May 22, 2013, 08:39:31 pm »
How does this compile? It looks like you are defining labels at runtime, even though labels are usually resolved to constants at compile time.
20
« on: May 22, 2013, 07:59:31 pm »
Ah yes, forgot that addresses point to bytes and not words, been toying with the dcpu16 architecture recently
21
« on: May 22, 2013, 07:07:17 pm »
This is interesting. I didn't realize that you could have variables other than the prenamed ones. I've never run out of the variables, but it would be nice to have meaningful names.
However I can't get it to work. I have this code:
PROGRAM:ΘTEST
.TEST
L₅→°FOO
L₅+1→°BAR
5→FOO
6→BAR
Disp FOO+BAR▸Dec
Which should display 11, but instead it displays 1547 (YMMV)
Am I missing something? Are you sure this is valid (it compiles, but maybe it means something else, though I can't think of what)?
22
« on: May 21, 2013, 10:44:47 pm »
I saw this topic from a while back: Ok, I have been trying out runer's sprite editor recently, which stored all sprites into an appvar which I couldn't decode (even with runer's help).
Even though I heard runer has been working on a new sprite editor, I decided to write my own.
This sprite editor stored the sprites directly into Pic5/Pic6 (frontbuffer/backbuffer respectively).
(It is your task to copy them to other pics/datafiles if you want)
It only supports 4lv grayscale.
I am not planning to support 3lv grayscale, nor any other features as this program is mainly meant for helping me completing zelda, I just decided to share it.
Controls:
Arrows - Move the cursor
F1 - Black
F2 - Darkgray
F3 - Lightgray
F4 - White
- - Go to the last sprite
+ - Go to the next sprite
Clear - Leave the program
Do not compile this program as an app, as it uses SMC.
Credits:
Me - Programming this app
Runer112 for the idea in the first place and help on how the Pic files are structured.
Bugs:
-It responds too fast
-You need to have Pic5 and Pic6 in the ram.
*I do not take any responsibility for any crashes/data losses caused by this program*
Don't let that spoil it tho, its a simple program allowing you to create 4lv grayscale sprites.
I thought the tool could be useful, but I found it almost unusable because it responded to key input too quickly. I hacked together a solution to that problem for my own use, but I figured there's no reason I shouldn't share it with you guys. As a bonus, I also increased to quality of the grayscale, retrofitting interrupts onto the old code (kind of ugly in one place, but it works). All credit to Ikkerens, who wrote the actual program. https://mega.co.nz/#!0wwXWbbY!fWFCr37nytZlUhKFimtGWA8obbdcbr-dEetMzZQGpyM
PS: I'm mostly a lurker on omnimaga and I can't figure out how to add attachments. Do I need a certain number of posts before I earn the right or what?
23
« on: May 30, 2012, 09:54:53 pm »
I'm thinking of implementing a FORTH environment in Axe. I think FORTH is a great environment for old devices like the TI 8x models, even though they are on the upper end of what I would consider FORTH appropriate for. I'm wondering if anyone else is interested in a dynamically compiled FORTH environment. The rest of this post is me rambling about specifics and somewhat less interesting stuff. I have a system set up for dynamic compilation of words into actual machine code. It's not the prettiest, and it could be about 2 machine instructions per word (as in FORTH word) more efficient if I were willing to write it in assembly, but I think the way I have it is good enough efficiency-wise and also lets me write all but 3 lines in Axe. I basically have an implementation of linked lists, except instead of a list it's a subroutine. :lbl BCONS
:⋿CD→{r₁}
:r₂→{r₁+1}ʳ
:⋿CD→{r₁+3}
:r₃→{r₁+4}ʳ
:⋿C9→{r₁+6}
:Return(the above code has unicode characters, if it doesn't display right for you I have a less pretty version below) funny story about how I came up with that code: So it can be called like this: :Buff(8)→GDB0
:BCONS(GDB0,λ(5→A),λ(A*2→A))
:0→A
:(GDB0)()
:Disp A▶DEC(no unicode version) That's not all there is so far, but there's not really anything else that's interesting yet.
24
« on: October 18, 2011, 08:13:41 pm »
I think I understand the concepts of axe, but I'm a bit confused about how to type some symbols I was working with subroutines and needed the r1-r6 variables. I did [alpha]+[alpha]+ - +[1] (lowercase r, 1) but the compiler gave me a symbol error. How am I supposed to enter these variables?
25
« on: October 18, 2011, 06:56:25 pm »
It's very likely that this has already been requested, but I'm not about to scan all 531 pages of feature requests. The concept of returning a value would be useful. Since there is no multithreading, you could designate some free memory to serve as a return value store.
Example (substituting the address of the return value memory with `R`):
sub(STUFF, 1, 2) -> A
Disp A>Dec
Lbl STUFF
Return r1*2+(r2*2)
would be read as:
sub(STUFF, 1, 2)
R -> A
Disp A>Dec
Lbl STUFF
r1*2+(r2*2) -> R
Return
It just seems strange to me to have lambdas but not return values.
|
Show Posts
