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 ... 30 31 [32] 33 34 ... 153
466
« on: November 27, 2013, 01:21:18 am »
The simple answer is just draw them to a front buffer and back buffer like normal, but use GB1 and GB2 as the front and back buffers, respectively. I whipped up the classic single-sprite-moving-around-on-the-screen demo for GrayLib. Code and screenshots and stuff below. The code is also attached in 8xp form, one file with the comments below and one with them stripped out.  .GRAYSPRT
.An example GrayLib program by Runer112
.==GrayLib==
.4-level grayscale, 83+ support, GDisp(), GDisp() clears, GTune() (and first run auto run), GWait(), getKey support (always on)
1→°G4→°GS83→°GID→°GDC→°GIGT→°GIW→°GSGK
prgmGRAYLIB
.==SETUP==
.Enable grayscale
GLoad()
.Sprite X and Y positions
16→X→Y
.==MAIN==
.Main loop
While 1
.Increment or decrement X by 2 if right or left is pressed, respectively, and increment or decrement Y by 2 if down or up is pressed, respectively, not letting the sprite go offscreen, and draw the first layer of the 8x8 grayscale sprite
Pt-Off(getKey(3)*2+X-(?getKey(2)*2)+(≤88-1*2)→X,getKey(1)*2+Y-(?getKey(4)*2)+(≤56-1*2)→Y,Pic0,GB1)
.Draw the second layer of the 8x8 grayscale sprite
Pt-Off(X,Y,Pic0+8,GB2)
.Wait until the last frame has been fully dispalyed with each dither mask
GWait()
.Mark the new frame for display
GDisp()
.If VARS was pressed, run grayscale tuner
!If getKey xor 23
GTune()
End
.End the main loop if CLEAR was pressed
End!If xor 24
.==TEARDOWN==
.Disable grayscale and quit
Goto GUnload
.==DATA==
.8x8 grayscale sprite
[FFFFC3C3C3C3FFFFFF81BDA5A5BD81FF]→Pic0
467
« on: November 27, 2013, 01:00:38 am »
The answer is probably MemKit. ---------------------------------------------------------------------------------------------
New(PTR,OFS,SIZ) Arguments: PTR = Pointer to start of program/appvar (from getcalc).
OFS = Offset in program to add memory
SIZ = Size of memory to insert
Returns: 0 if it failed, non-zero if it succeeded.
Description: Attempts to inflate the size of a program/appvar
---------------------------------------------------------------------------------------------
Delete(PTR,OFS,SIZ) Arguments: PTR = Pointer to start of program/appvar (from getcalc).
OFS = Offset in program to start deleting memory
SIZ = Size of memory to delete
Returns: 0 if it failed, non-zero if it succeeded.
Description: Attempts to shrink the size of a program/appvar
---------------------------------------------------------------------------------------------
468
« on: November 26, 2013, 01:59:09 pm »
That Axiom is greeat, even in GrayLib (I don't understand how Runer's commands work)
So many people are making IDE's  good luck! I certainly would love one just for the small font, it's too easy to get "lost" in your code with the big font.
That Axiom is greeat, even in GrayLib (I don't understand how Runer's commands work) Same, I checked it out earlier today and it confused me...
You can post in the GrayLib thread and ask questions, you know. I promise I won't bite. 
469
« on: November 22, 2013, 06:05:05 pm »
* Runer112 points to his reply in your existing program icon topic
470
« on: November 20, 2013, 06:31:34 pm »
I am strongly of the opinion that this cannot be solved simply by filling in angle values using geometric rules. Although the answer does come out to an integer, adjusting one of the starting angles slightly to a different integer results in the answer coming out as irrational, which would thus not be obtainable by application of simple geometric rules. So I believe trigonometry is required. Which I applied to get my solution, which I will withhold for now. EDIT: Here's a modified picture with some suggestions which hint to how I solved the problem with trigonometry and algebra. EDIT 2: And here's the worked out solution. Each step is nested in a spoiler, so only peek as much as you need to!
471
« on: November 18, 2013, 03:41:38 pm »
I tried changing the target name in the header of a random large source to IkarugaX and added a description, but everything still seemed fine.
EDIT: Nevermind, I replicated it. Trying to solve now.
472
« on: November 18, 2013, 02:58:21 pm »
I've tried to replicate that with a few different sources, including a large one that spans two flash pages, which has caused error scrolling issues in the past, but I couldn't recreate the bug you're describing. Do you think there are any other details you could provide to narrow down the cause?
473
« on: November 14, 2013, 11:25:20 pm »
I'm just going to bug you about making an 84+CSE version of zStart, in case you haven't been bugged about it enough yet. It would be quite nice. If you wanted any assistance porting it or testing it, I would offer my help.
I'm probably never going to own a CSE, so someone besides me is going to have to do it. I'll answer any questions said person has along the way and even find the OS entry points, but I don't want to actually do the porting.
I think I'd be up for doing it. Can we make an exhaustive list of everything that would need to be altered? I'll try to name as many things as I can: - App needs new graphics
- Run on RAM clear patch needs to be adjusted (New flash unlock needs to be used?)
- Startup picture feature needs to be changed to some color format or removed
- Catalog help and Omnicalc settings need to be removed
- Contrast level saving needs to be changed to backlight level saving
- LCD delay settings need to be removed
- Custom font hook possibly needs to be adjusted
- Font creator/editor needs to be adjusted and graphically redone
- Text popups on key combos should be moved into status bar
- Axe settings need to be removed
- Label browser for BASIC programs needs to be graphically adjusted
- Anything that deals with swapping flash/RAM pages
474
« on: November 14, 2013, 09:20:24 pm »
I'm just going to bug you about making an 84+CSE version of zStart, in case you haven't been bugged about it enough yet. It would be quite nice. If you wanted any assistance porting it or testing it, I would offer my help.
475
« on: November 14, 2013, 12:10:48 pm »
I think I will start an editor in a little while, I really want one too mostly just for the tiny font.
Runner112, is there any way you could make Axe so that I could make an app greater than 16384 bytes? My current program has gotten so large I have had to cut some features that I didn't want to cut just so it could compile.
This is something that will require a compiler redesign and should hopefully come with Axe 2.0. But that's still a long ways off, I feel. For now, your options are to optimize your code (you can post the source or parts of it and request optimization help on the forums, if you'd like), and/or follow Matrefeytontias' suggestion to compile it as a program with Fullrene, which would realistically let you have programs up to about 20-24KB.
476
« on: November 13, 2013, 01:31:22 pm »
Another bug with Axe 1.2.2 : it seems that you forgot to check whether we compile as an app or not before saying "APP TOO BIG". I want to compile a 16464 bytes MirageOS program, but it won't do.
1097E710AFA74E43
A668A668DB990012
0B378B810011FF00
040A406D4AD14976
Sorry, fixed! Also, I probably should've gotten into this habit a while ago, but I'm going to make my development builds publicly available. That way, if I made a silly bug like this and fixed it really easily, but haven't made enough changes to warrant a new release version of Axe, you can still get the bug fix. Also, if anyone requests a feature and I implement it, they can test it out as soon as I'm done coding it. Ideally, this should be the link for this and all future development builds, at least of the Axe 1.x line: https://dl.dropboxusercontent.com/u/34812306/Axe.8xk
477
« on: November 09, 2013, 03:04:07 pm »
Clipped lines are tough (to do optimally in assembly, at least) and I've been dreading coding them forever. But I'll bump it up on my priority list and try to force myself to implement them sooner rather than later.
478
« on: November 08, 2013, 03:08:33 am »
You could try to scan the executable for any assembly instructions in the program that call or jump to a shell routine vector. It's not foolproof, but it should ideally only rarely incorrectly determine if the program has a shell dependency, and when it does do it incorrectly, it hopefully would be a false positive more often than a false negative.
479
« on: November 07, 2013, 05:44:23 pm »
Properly dithered grayscale should be fine. However, flashing large areas of the screen on and off together near the LCD's refresh rate is not fine. It may look interesting, but don't do it.
480
« on: November 03, 2013, 03:50:48 pm »
Tip: Use #ExprOn (that's normally the ExprOn token) anywhere before Horizontal+/- in your program and it becomes pretty much just as fast as Vertical+/-, at the cost of a 28-byte larger, speed-optimized routine. A few other routines have speed-optimized versions and also get speed benefits (with size costs) from #ExprOn, including ►Hex, DrawInv, and multiplication, and additionally Pt-On(), Pt-Change(), and Pt-And() if not compiling your code as an application.
If you want to speed it up even more, shift in more than one pixel per new frame. Each additional pixel shifted and redrawing of the tunnel will of course make each frame take longer to render and thus decrease the framerate, but you might be able to get away with a couple extra shifts per frame without noticeable choppiness.
Pages: 1 ... 30 31 [32] 33 34 ... 153
|
Show Posts
