Author Topic: Features Wishlist (Read 705608 times)

Munchor · « **Reply #1680 on:** December 23, 2010, 04:42:11 pm »

It's OK, I don't see the point of it that much... Is it thatfaster?

Deep Toaster · « **Reply #1681 on:** December 23, 2010, 04:44:02 pm »

According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Seems like a useful command

I was just about to ask for DispGraph^rClrDraw/DispGraph^rrClrDraw, but then I realized how pointless it'd be (there'd be no grayscale anyway if you're clearing it every pass).

Munchor · « **Reply #1682 on:** December 23, 2010, 04:45:03 pm »

Quote from: Deep Thought on December 23, 2010, 04:44:02 pm

According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Oh I see. Nice then, I refer to: "you're saving all the time it takes to clear the graph buffer.".

Happybobjr · « **Reply #1683 on:** December 23, 2010, 06:21:43 pm »

Quote from: Deep Thought on December 23, 2010, 04:44:02 pm

According to Quigibo it's about the same speed as just DispGraph, so you're saving all the time it takes to clear the graph buffer.

Seems like a useful command I was just about to ask for DispGraph^rClrDraw/DispGraph^rrClrDraw, but then I realized how pointless it'd be (there'd be no grayscale anyway if you're clearing it every pass).

why wouldn't there be?

Compynerd255 · « **Reply #1684 on:** December 24, 2010, 12:48:18 am »

Quote from: ScoutDavid on December 23, 2010, 04:37:17 pm

Quote from: graphmastur on December 23, 2010, 04:35:42 pm
Quote from: Qwerty.55 on December 23, 2010, 02:28:48 am
Quote from: Deep Thought on December 22, 2010, 12:19:34 pm

And objects, or course

Hopefully not. I don't like OOP.
I actually love OOP, but it's not for Axe. Maybe another language altogether.

There are languages that can be OOP, but not fully OOP, like Python.

Not to break the DispGraph:ClrDraw feature discussion all of a sudden. I think it does sound cool.

You know, you could actually do something like OOP very easily in something like Axe. Since I am a C# programmer, I think in objects a lot, and find myself using idioms for multidimensional arrays ({I*3+2+L1} or whatnot) to reference objects. This is my idea of how it could be implemented:

- Somewhere in your code (such as in a library) you write this:
Class(NME
Var(X,2)
Var(Y,2)
Var(S,8)
End
This creates a class called NME with a 2-byte X, a 2-byte Y, and an 8-byte S

- Then, somewhere else in your code, you write this:
Instance(NME, JOE, L1
This will tell Axe that you want an instance of NME named JOE at L1

- Then you can do things with the object:
"JOE(X)" returns the value of JOE's X
"3->JOE(X)" stores the value into JOE's X
"Pt-On(JOE(X),JOE(Y),JOE(S)<degree symbol>)" will draw JOE to the screen.

- You might even want subroutines inside the object itself that omit the JOE( part, so you can simply call JOE's version of the subroutine to have JOE preform operations on himself.

But you can do what you want. I just think that OOP would be really cool.

Quigibo · « **Reply #1685 on:** December 24, 2010, 04:34:57 am »

As much as I would like to do OOP, there just simply aren't enough resources on the calculator to handle all the overhead that would take in the parser.

I finally moved the default location of the variables to the end of L1 instead of the beginning and I'm in the process of writing the #Realloc() routine to move them anywhere else. I decided to make all the compiler instructions have the '#' prefix so they don't get confused with actual commands. So far, the only other token that has changed is "#Axiom()" but "#Icon()" will be coming soon and I'm pretty sure you can guess what that does

Another thing I noticed that I can't believe I didn't see before was to move the random seed away from the variables and into the hidden buffer (the one I'm using for r1-r6, files and other smaller things). This expands the usable memory in L1 by 2 extra bytes! It was actually kind of a necessity rather than a choice though because the Rand routine uses a fixed location to get the seed. If the variables included the seed and then got reallocated, the Rand routine would no longer be looking at the correct location so you could get glitches if you tried to use all of L1 for something. So it was a win-win to move it.

shmibs · « **Reply #1686 on:** December 24, 2010, 04:47:01 am »

YAY FOR CUSTOM ICONS!

oh, and does this mean that variables can be moved, if one chooses, to one of the smaller L's, meaning the L1 area can be used as another buffer?

Quigibo · « **Reply #1687 on:** December 24, 2010, 04:54:25 am »

That's exactly the intention.

In fact, you don't need them to be in any of the L1-L6 buffers at all if you're compiling for a shell/noshell. You can store them directly in your program:

Code: [Select]

:Zeros(54)->Str1V
:#Realloc(Str1V)

squidgetx · « **Reply #1688 on:** December 24, 2010, 08:13:32 am »

Damn, all these improvements are sounding really nice. I can see potential uses for all that stuff.

By the way, where's the "hidden buffer"? I want to make sure that while I'm hunting down potential freeram areas that aren't in L1-L6 (like in $8000) that I won't accidentally use that area too

Runer112 · « **Reply #1689 on:** December 24, 2010, 04:06:15 pm »

The "hidden buffer" is MD5Buffer, a 64-byte section of RAM starting at $83A5. I wonder what immediately follows it in RAM, because if there were only a few more byte of safe to use RAM, you could move all the variables there.

Quigibo · « **Reply #1690 on:** December 24, 2010, 04:10:09 pm »

Not really, I'm already using 6*2 = 12 for the r1-r6 variables, 10*3 = 30 for the Y0-Y9 files, 2 for the random seed, and 8 for the sprite buffer. That totals 52 bytes so I really only have 12 bytes left

Edit: Also, I added >Hex finally

Runer112 · « **Reply #1691 on:** December 24, 2010, 04:14:21 pm »

Oh wow, didn't realize all that other stuff was there too. Nevermind then!

And thanks for adding ►Hex, that should make debugging easier. By the way, can we also use ►Hex outside of text display commands? Perhaps have the hex string be generated to a 5-byte section of MD5Buffer and return a pointer to it? Because then it could also double as a useful and quick hex generator that we can just copy the data out of.

Quigibo · « **Reply #1692 on:** December 25, 2010, 12:10:25 am »

Runner, that would make the routines a lot larger and I don't think it would be as used often enough to justify the extra size.

I optimized the 3 level grayscale routine more. Its 5 bytes smaller and the inner loop is 20 T-states faster. The inner loop iterates 768 times per frame at 6MHz which results in the overall routine being 2.5 milliseconds faster per frame. That's about a 4% speedup for a game running at 15fps. The grayscale is smoother too.

The only thing I'm worried about is that there's only 57 T-states between LCD driver commands at one point (which is not including the 11 T-states of the "out" instruction). The z80 in 28 days tutorial recommends 60, but the routine works on my 84+ which has the bad LCD. Anyone willing to test this on hardware? I attached an example that uses the routine.

Raylin · « **Reply #1693 on:** December 25, 2010, 12:47:31 am »

I shall test ASAP.

Dang. Never mind.
Ubuntu says no.

Runer112 · « **Reply #1694 on:** December 25, 2010, 01:27:45 am »

Quote from: Quigibo on December 25, 2010, 12:10:25 am

Runner, that would make the routines a lot larger and I don't think it would be as used often enough to justify the extra size.

I don't know how small you managed to make the current routine, but mow much larger could this make it? The following routine I whipped up would take input in hl, convert into a null-terminated string of hexadecimal characters starting at vx_Hex, and return a pointer to that string. It's only 29 bytes. To display a string you would just call this and then treat the result like any normal string. But you now have the extra advantage of being able to access the generated hex characters.

Code: [Select]

p_ConvHex:
	ex	de,hl
	ld	hl,vx_Hex+4
	xor	a
	ld	(hl),a
	call	__ConvHexByte
	ld	e,d
__ConvHexByte:
	ld	a,e
	call	__ConvHexNib
	ld	a,e
	rra
	rra
	rra
	rra
__ConvHexNib:
	or	$F0
	daa
	add	a,$A0
	adc	a,$40
	dec	hl
	ld	(hl),a
	ret

Author Topic: Features Wishlist (Read 705608 times)

Munchor

Re: Features Wishlist

Deep Toaster

Re: Features Wishlist

Munchor

Re: Features Wishlist

Happybobjr

Re: Features Wishlist

Compynerd255

Re: Features Wishlist

Quigibo

Re: Features Wishlist

shmibs

Re: Features Wishlist

Quigibo

Re: Features Wishlist

squidgetx

Re: Features Wishlist

Runer112

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Runer112

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Raylin

Re: Features Wishlist

Runer112

Re: Features Wishlist