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 - Runer112
Pages: 1 ... 111 112 [113] 114 115 ... 153
1681
« on: November 30, 2010, 06:14:22 pm »
It's not a bug. There are 65536 bytes in RAM, which can all be accessed with a 16-bit pointer, but there are twice as many nibbles. Because of this, you cannot access every nibble in RAM with a 16-bit argument, so it is split into two commands. nib{} will return a nibble from ᴇ8000-ᴇFFFF, and nib{}ʳ will return a nibble from ᴇ0000-ᴇ7FFF. Applications reside in RAM from ᴇ4000-ᴇ7FFF, so you need to use the nib{}ʳ command when compiling to applications.
1682
« on: November 30, 2010, 10:42:00 am »
By the way, isn't Data(4,TAns,0,0) simply "Ans" in quotes? That should work, if it doesn't then its a bug I need to fix.
"Ans" is just $72. Store it to a pointer and you'll get $72,$00, but that's still far off from $04,$72,$00,$00.
1683
« on: November 30, 2010, 10:34:06 am »
As shmibs suggested, the most basic way to access an array of sprites is to simply put the data for the sprites all in succession and then access the sprite you want by adding an offset to the base pointer. For example:
[FFFF000000000000]→Pic1
[FFFFFFFFFFFFFFFF]
... Lots of sprites formatted like above and below
[A5229EFF667DCB00]
.Draw sprite 0
Pt-On(0,0,Pic1)
.Draw sprite 1
Pt-On(10,0,8+Pic1)
.Draw sprite 8
Pt-On(20,0,64+Pic1)
.Draw sprite N (0-indexed)
Pt-On(30,0,N*8+Pic1)
What I demonstrated above is probably the preferable method for displaying sprites from an array of sprites. However, if there's no way you can have the sprites occupy a contiguous array in memory and you require a list of pointers, you would do something like this:
.For this example, you have sprites at Pic1, L₁, and 64+L₁
[FFFF000000000000]→Pic1
Data(Pic1ʳ,L1ʳ,64+L1ʳ)→GDB1
.Draw sprite 0
Pt-On(0,0,{GDB1}ʳ)
.Draw sprite 1
Pt-On(10,0,{2+GDB1}ʳ)
.Draw sprite N (0-indexed)
Pt-On(20,0,{N*2+GDB1}ʳ)
1684
« on: November 29, 2010, 04:26:47 pm »
Export function, thats what I've missed in your last version xD
It's already in the list, bundled in with an import function. Also would this be an APP? The issue with the other tilemapper was having to archive/unarchive everything back and forth during development. I know I can use Doors or CalcUtil, but when I develop, I prefer that no other ASM stuff is being used on my calc. In other words, only Axe and my work will run. It's quite easy to mess something up in Axe and if it happens to conflict with CalcUtil or Doors it has higher chances to mess things up.
There are multiple reasons that this will definitely be an application: - Running the program as an assembly executable would take up a large portion of user RAM just to hold the executable. This will leave little free space for anything else, like the data appvar.
- The finished program will undoubtedly be larger than the assembly executable code limit. (I hope I can even fit it into an app!)
- This will leave more user RAM free, allowing all data to exist in RAM. This (hopefully) means no constant unarchiving and archiving will be necessary.
- Leaving more user RAM free will also allow for the free space to be used as an extensive undo/redo history.
- It seems more suitable for large utilities like this to be an application, anyways.
1685
« on: November 29, 2010, 03:47:44 pm »
I haven't really thought about how the tilemap editor will end up, but that's a nice idea. And I've already built room into the tilemap filetype's metadata to support any tile bit depth from 0-15.
1686
« on: November 29, 2010, 03:42:33 pm »
From what I can tell, that code will shift every other byte, starting at L1+3, backwards 2 bytes in memory. A total of 6 bytes of data will be moved. I may be wrong, but I'm guessing that this is not the effect you wanted to achieve? Before:
| Address: | L1 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 | +12 | +13 | | Data: | A | B | C | D | E | F | G | H | I | J | K | L | M | N |
After (changes in bold):
| Address: | L1 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +10 | +11 | +12 | +13 | | Data: | A | D | C | F | E | H | G | J | I | L | K | N | M | N |
1687
« on: November 29, 2010, 02:17:23 pm »
aeTIos, all I've been able to draw from what you've said is that you want code to randomly generate levels for a sidescroller. I believe I speak for all of us when I say that this is too vague to understand what exactly you want. Despite how much we may want to help, we really can't help you until we have a better idea of what you want.
1688
« on: November 29, 2010, 10:34:32 am »
You lost the If before Z=3. Which means you're also missing an End to close the loop it's in.
1689
« on: November 29, 2010, 08:56:29 am »
If A<<0
90->A
ClrDraw
Pt-Change(A,0,Pic1
DispGraph
End
1690
« on: November 28, 2010, 11:45:20 pm »
The problem with compiling multi-page apps is not that writing the extra app pages to flash would be dangerous. The problem is adapting the compiled code to include page swapping. It's hard enough to get it to work for a program that you coded yourself in assembly, knowing where the routines and data are. It's even harder to get it to work for arbitrarily coded programs.
1691
« on: November 28, 2010, 11:07:09 pm »
Creating Ans as a string:
Data(4,ᵀAns,0,0)→Str0AN
DelVar Str0AN
GetCalc(Str0AN,size_goes_here)
1692
« on: November 28, 2010, 11:04:28 pm »
Well, for one thing that code is a little different from mine (missing a ,4). But on the other hand, I just tried it now, and there is a bit of a glitch with Axe. This code only works if Ans was previously a string. The reason is that when Axe looks for an existing Ans variable to delete, it's looking for a string (and type matters because it's using chkfindsym). If it searched using findsym, it would work (but would fail for programs and appvars).
A simple fix that should always successfully create Ans as a string: Data(4,ᵀAns,0,0)→Str0AN
DelVar Str0AN
Copy("TEST",GetCalc(Str0AN,4),4)
1693
« on: November 28, 2010, 06:21:36 pm »
"Static data can be stored to variable pointer."
How exactly does this work?
You can now do: "0123456789ABCDEF"→AInstead of having to previously have done something like: "0123456789ABCDEF"→Str1
Str1→AIs there an Input command, I heard DJ saying it was something like
Z->input
But maybe I misunderstood :S
There is an input command, and it returns a pointer to a string of tokens, not a numerical value.
1694
« on: November 28, 2010, 06:04:40 pm »
Cool, Quigibo added all my optimized auto-optimizations  But I think you missed p_GetBit15, which can be optimized to be the same as p_Mod2.
1695
« on: November 28, 2010, 09:38:34 am »
That's a lot of features O_o
I can only think of a couple things that are missing:
Ability to scroll (So we can edit, say, a 32*32 sprite at 4x zoom)
Cut/Copy/Paste (Box selection, unless you really want to add the ability to deal with user-drawn shapes  )
Can't wait to see if you implement this!
Both of those were features that had crossed my mind but I never wrote down. I'll add them to the list and make sure that whenever I build the editing platform, it's very flexible and can support things like arbitrary zoom levels and scrolling. Does it work with frames/animations already? if it doesn't, I'd like to see that too
I already have planned animations as a potential feature, although I haven't worked on it (or most things on that list). Most of what I've worked on so far is the filesystem itself and making sure I set up a framework that will support a vast array of features, like animations.
Pages: 1 ... 111 112 [113] 114 115 ... 153
|
Show Posts