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 ... 128 129 [130] 131 132 ... 153
1936
« on: October 07, 2010, 01:00:10 am »
Haha everybody is making a Zelda clone  EDIT: Hehehe
1937
« on: October 06, 2010, 11:46:12 pm »
I personally like the left one better, but what about a transparent background that animated? Like some scrolling light grey diagonal lines to show through the sprite to make everything more noticeable?
Well that would just be a pain lol.
1938
« on: October 06, 2010, 11:18:39 pm »
Yeah, but that would mean a darker gray is used for transparency, which might not look good in many situations. I vote left...
EDIT: Maybe you could post more examples? If we were to vote based on how it looks, the sprite on the right definitely looks better.
Yeah, I probably should post more examples. Especially because the Zelda sprite was designed to have the coloring of the sprite on the right, so it will naturally look better.
1939
« on: October 06, 2010, 10:02:27 pm »
A bunch of people have been pestering me about the dysfunctionality of an old sprite editor of mine, so I'm working on it again. I plan to support masked 3-color (black, gray, and white) grayscale sprites, and I want the user to be able to see transparency. To do this I'm going to display the sprite in 4-color grayscale, with transparent being represented as one shade of gray and actual gray being the other shade. The question is, which method looks better: transparency being represented as light gray (left) or dark gray (right)? I'm torn because, to me, the option on the left better portrays the sprite being over a transparent layer, but in the option on the right, the sprite itself simply looks better. Another image (also, sneak peak at the epicness that will be the new sprite editor - note the full filesystem - no, it's not just a mock-up): Another, with non-Zelda sprites:
1940
« on: October 06, 2010, 08:10:33 pm »
I just wanted to pop in and say something. Im worried that having a super faster routine for sprites isnt going to help your speed as much as you think it might. I ran some tests with the regular Axe sprite routine and i was able to display over 4000 a second even in 6Mgz mode. In the other thread you said you needed over 2000 per second, so im worried that some of the slowdown isnt coming from the sprite displaying. Have you tried out your routine in the program? Im eager to hear new details! I really hope everything works out 
The routine works, and I can get 22 full redraws and DispGraphrr's per second vs. 20 with the normal sprite routine, so I'm happy with the result. I think that, for the animation speed I want, I'll only need to redraw the screen 12 times per second, which will then allow me to increase my number of DispGraphrr's per second and (hopefully) result in fairly smooth grays.
1941
« on: October 06, 2010, 08:04:55 pm »
Shouldn't be too hard the only challenge, as far as I can see, would be the parsing of the VAT. The rest is just playing with a string. I'm just not comfortable with the VAT enough to do it myself.
As nemo pointed out, Quigibo wrote a few subroutines that can parse the VAT for you. Call sub(VI) to start off. Then, check the current entry's name, which is stored backwards with the first token at sub(VN), call sub(VNX) to move to the next VAT entry, and if not at the end of the VAT, repeat.
1942
« on: October 06, 2010, 06:09:25 pm »
If you want the compiled Axiom, here it is. It draws 8x8 aligned grayscale sprites to arbitrary buffers. It uses the Plot2( token, and although the parenthesis would suggest otherwise, it's actually set not to accept any arguments. You have to store the arguments into r 1-r 5 manually, and don't put an ending parenthesis after Plot2(. The reason I did this is so you can save some processing time when displaying a whole tilemap by, instead of doing something like: For(B,0,7)
For(A,0,11)
Plot2(A,B,calculation for sprite pointer,L₆,L₃)
End
End
You can do this: L₆→r₄
L₃→r₅
For(r₂,0,7)
For(r₁,0,11)
calculation for sprite pointer→r₃
Plot2(
End
EndThis saves a bit of processing time for a whole 12x8 tilemap by only storing one argument variable per iteration instead of five. (In case you couldn't tell from the code example, the arguments are as follows) - r1 = Sprite row (0-11)
- r2 = Sprite column (0-7)
- r3 = Pointer to 8x8 grayscale sprite
- r4 = Front buffer pointer (L6 if you're not doing anything special)
- r5 = Back buffer pointer (L3 if you're not doing anything special)
EDIT: Edit: Is there some special way you have to compile Axioms? Because I can't figure out how.
If you look at my Axiom source from the first post, you can see what the .z80 file should look like. Then you need to assemble it and convert it to an appvar. Personally, I deal with this conversion by sending the program to wabbitemu and using Calcsys to change its type.
1943
« on: October 06, 2010, 05:01:25 pm »
They were disabled is for 2 reasons.
First of all, I wasn't sure if they still worked or not after mixing subroutines and data because I didn't do any testing with them after making this change. But it sounds like they probably do work so I guess it's just lucky that it still functions without having debugged. There might be other problems still with subroutines, token names, compatibility options, or at least some combination probably still doesn't work.
The other issue is that I am completely changing the axiom capability with "acalls". The acalls are similar to bcalls except they call axe routines instead of OS routines. They're basically just jumps whose label gets automatically replaced by the parser with the label of the axe routine in the program, inserting the routine into the program if it doesn't already exist. Works with all conditionals of jumps and calls too. Another new feature is adding options for the r modifier or double rr modifier to be used with axioms. There is also a new form for implicit storing where you can store to the function itself like how ->nib{} would work for example. With all these changes, the code was completely under construction so rather than commenting it out and replacing it with the old code, I decided to just keep it there but have it disabled until I actually finish it.
Well don't change it too much, I have it working now and wouldn't want to have to completely reformat it for a new system 
1944
« on: October 06, 2010, 03:28:53 pm »
It looks like Axioms do in fact work! My routine works without crashing my calculator, and almost does exactly what I wanted it to! The only problem is that it seems to be ignoring the sprite row input and draws all sprites to the second sprite row (row 16 of the display). Anybody see a problem in my code that might be causing this? EDIT: It completely works now! Although I realize this is a very specific routine, if you're drawing 8x8 aligned grayscale sprites, this routine can draw the sprites in about 2/3 of the time that the combination of Pt-Off() and Pt-Off()r can 
1945
« on: October 06, 2010, 12:32:59 pm »
Wow, in my whole process of register juggling I completely forgot that pushes and pops exist lol. Silly me
1946
« on: October 06, 2010, 05:06:45 am »
I'm not quite sure where to post this, in here or in the ASM forum... but although Quigibo disabled axioms in 0.4.5, I decided to write one anyways It's an 8x8, aligned, grayscale sprite routine that can write to arbitrary buffers! And at 15MHz it could draw OVER 9000 GRAYSCALE SPRITES PER SECOND!!! That is, if it worked... Running it as part of a program compiled with version 0.4.4 freezes my calculator (The axiom did partially work ONCE without crashing my calculator though, the first time I tried it). I'm not sure if the problem is in my code or the Axiom system. Quigibo, was the Axiom system removed because it was damaged? Or is my code probably the damaged part, whether it's a problem with the axiom or how I use it in my program? I don't know if assembly code should even be posted here, but if you want to look at the source and tell me the numerous things I did wrong (besides cheating the normal axiom argument system, that's intentional and should work fine), here it is: EDIT: Changed iy usage to push/pop, still crashes my calculator. EDIT 2: THE AXIOM FUNCTIONS WITHOUT CRASHING, YAY! But it still doesn't do what I want, which I presume is just a problem with my code. It seems that it's ignoring the row input and always drawing sprites to the 2nd sprite row (row 16 of the display). Any ideas?
EDIT 3: IT COMPLETELY WORKS!!! If you want to use it (not in Axe 0.4.5 though), it's attached to this post.
.nolist
#include "ti83plus.inc"
.list
.org $9D95
#define var_r1 $83A5 ;Sprite column (0-11)
#define var_r2 $83A7 ;Sprite row (0-7)
#define var_r3 $83A9 ;Pointer to 8x8 grayscale sprite data
#define var_r4 $83AB ;Pointer to front buffer
#define var_r5 $83AD ;Pointer to back buffer
.dw $C0DE ;Header
.db $FF ;Shells
.db tPlot2,0 ;Token
.db 0 ;Replacement Type
.db 0 ;Arguments
.db 56 ;Size
;Calculate byte offset
ld a,(var_r2) ;[13] Sprite row (0-7) -> Multiply by 96 for byte offset (0-672)
add a,a ;[4] *2
add a,a ;[4] *4
add a,a ;[4] *8
add a,a ;[4] *16
add a,a ;[4] *32 (0-224)
ld h,0 ;[7] Move to hl to avoid overflow
ld l,a ;[4]
ld d,h ;[4] Copy hl to de to prepare for *3
ld e,l ;[4]
add hl,de ;[11]
add hl,de ;[11] *96 (0-672)
ld a,(var_r1) ;[13] Sprite column (0-11)
add a,l ;[4] Add to byte offset (will not overflow, l mod 32 = 0)
ld e,a ;[4] Move result to de
ld d,h ;[4]
ld hl,(var_r5) ;[16] Back buffer pointer
add hl,de ;[11] +offset
push hl ;[11] Save for later
;Prepare to copy sprite to buffers
ld hl,(var_r4) ;[16] Front buffer pointer
add hl,de ;[11] +offset
ld ix,(var_r3) ;[20] Sprite data
ld de,12 ;[10] Row increment
ld c,2 ;[7] Buffer counter
putSpriteLoop1:
ld b,8 ;[7] Row counter
putSpriteLoop2:
ld a,(ix) ;[19] Copy a byte from the sprite to the buffer
ld (hl),a ;[7]
inc ix ;[10] Move forward 1 byte in sprite
add hl,de ;[11] Move forward 12 bytes in buffer
djnz putSpriteLoop2 ;[13/8] Repeat for 8 rows
dec c ;[4] Decrease buffer counter
jr z,end ;[12/7] End if done with both buffers
pop hl ;[11] Retrieve back buffer pointer+offset
jr putSpriteLoop1 ;[10] Repeat for second buffer
end:
.end
1947
« on: October 05, 2010, 10:49:04 pm »
I'll definitely check out that bcall.
@Runer
If the sprite is 16x16 (and aligned to an 8x8 grid no clipping), you can actually write your own sprite routine in Axe itself that would be more efficient than drawing 4 8x8 sprites by copying the sprite data to the L6 buffer directly. I'm pretty sure I've seen someone do that before but I can't recall the thread... For 8x8 sprite drawing routines though, the speed would not be that significantly increased since the sprites are automatically not shifted when aligned to the grid anyway and clipping is a relitively small portion of the actual time it takes to draw a sprite. Aligned sprites draw fastest with Pt-Off() whereas unaligned sprites draw fastest with Pt-On() and Pt-Change().
Yeah, I realize the speed increase wouldn't be terribly much, but I could use all the speed I can get. For what I'm trying to achieve, I need to draw about 2,000 sprites per second. I might try my own hand at the routine, but I get the feeling I'd end up writing it in such an unoptimized way that it would even be slower then a full-featured routine.  Is there just a basic, unaligned 8x8 sprite routine without clipping floating around somewhere that I could steal? By the way, what happened to Axioms?
1948
« on: October 05, 2010, 07:49:22 pm »
Yep, I know they're in the archive (somewhere near the end on the last page, I think). But does anyone know the address in memory? I need to see if certain routine is working and the only way to do that is by giving it a specific area of memory to read. Unfortunately, the only area of memory that I can visually check happens to be those sprites, which I don't know the address of.
What routine is this? Unless your routine is an Axe/asm hybrid with the ability to read from arbitrary places in ROM, you're not going to be able to access this. Why do you want to access the font images anyways?
1949
« on: October 05, 2010, 06:45:53 pm »
Why would animated tiles be any slower than regular tiles? Don't you have to display them every frame anyway?
Why would you need to display static tiles every frame? You can just draw them once and repeatedly display that rendered image. Whereas you'll need to render animated tiles over and over.
1950
« on: October 05, 2010, 05:14:35 pm »
Dang, I just realized that Quigibo disabled Axioms with the last update... I'm guessing he's reworking them. But anyways, when they've been reworked and are enabled again, could someone (maybe even Quigibo as an example Axiom) make a fast sprite display routine? When I say "fast" I mean as fast as a sprite routine can possibly get: no aligning, no clipping, and with whichever display method/logic works fastest (it would be nice to be able to specify an arbitrary target buffer, though). The main reason I'm asking is because I've been working on something that uses an aligned tilemap system, but the tiles are animated, and updating the tiles constantly brings the program to a crawl.
Pages: 1 ... 128 129 [130] 131 132 ... 153
|
Show Posts
