Show Posts

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 - Quigibo

Pages: 1 ... 95 96 [97] 98 99 ... 135
1441
Axe / Re: Pointers memory location
« on: May 27, 2010, 02:11:02 am »
aaaah ok, well it was more for Kindermoumoute, who wanted to know how to copy a sprite from a pointer to another to no avail.
That's the copy command Conj().  You can use it to copy a sprite,  into for instance the L1 address, by doing conj(Pic1,L1,8)

1442
News / Re: Video tribute to Axe Parser project
« on: May 26, 2010, 02:19:31 pm »
But so far, I haven't seen any axe games uploaded to ticalc.org beyond this community.

Scratch that.  Just noticed one this morning and it was actually pretty good.  I'm hoping someone will make "Axe Murderer" which would be a game about a serial killer.  Maybe I'll do that eventually... (make the game I mean ;) )

1443
ASM / Re: Flickerless Grayscale
« on: May 26, 2010, 02:02:31 pm »
Really? for the grayscale in the games I've made, I always use 3/8 on for light gray (37.5%) and 5/8 for dark gray (62.5%).  Do other 4 level grayscale games use 1/4 and 3/4 for gray levels?  How would these be interwoven?

I would think it would have to be something like this for best results:
11101110
10111011
11011101
01110111

It seems hard to create this kind of cycle though.

1444
News / Re: Video tribute to Axe Parser project
« on: May 26, 2010, 04:40:22 am »
Nice!  I can see a lot of effort when into this, great variety of screenshots!  Excellent job :)

I hope it gets exposure, so more excellent games appear. Axe Parser can beat every interpreted language we could do for z80 in speed.

You know I have this little fear inside me, however small, that if it does get really popular, is there a likelihood we could see a new rush of "bad" games?  Imagine how the TI archives used to be with BASIC programs; many of them were pretty low quality with very little effort put into them becasue they were quick and easy to make.  I really hope that doesn't happen with Axe programs, I doubt it.  But so far, I haven't seen any axe games uploaded to ticalc.org beyond this community.

1445
ASM / Re: APP -- Sprites and text all messed up... why!?
« on: May 26, 2010, 04:15:27 am »
I think you're thinking of "VPutS" instead of "PutS".  You also change "PutC" to "VPutMap" and instead of using CurCol and CurRow you use PenCol and PenRow.  I'm surprised this worked in small font before as a non-app, that's strange...

The sprites not working now but working before sounds like you might still have some self modifying code.  Either that, or you're using some other bcall that can't be executed in the $4000 address.

1446
The Axe Parser Project / Re: Axe Parser
« on: May 26, 2010, 03:36:50 am »
Nope.  Only size decreases :D

1447
The Axe Parser Project / Re: Axe Parser
« on: May 26, 2010, 03:22:50 am »
@ztrumpet The [on] interrupt will come eventually.  But keep in mind that only protects you from infinite loops and NOT from writing data in the wrong places.  Also, it does not allow you to to use your own interrupts in this mode, however, you can still add quitting code in the custom interrupt yourself.


Well, I'm rewriting the way number parsing works.  I have to or else I can't implement some new optimizations.  I'm grouping every single routine that can possibly return a constant into a single read-number routine.  That includes Integers, Hex, Binary, Characters, Tokens(new), Pointers, and everything else.  The goal is to make all expressions that evaluate to constants be single constants, not just pointers.

Now, I ran into some really cool syntax problems.  I was going to include multiplication and division in these optimized routines which can really help sometimes.  For instance, when using *256 coordinates you can type 44*256 to make 44 the coordinate and Axe automatically multiplies this precompile time.  But then I realized there was a slight technical problem with doing this.  What if you typed A/2/2 to do faster division?  Axe would automatically optimize this to A/4 which although it is actually optimized in terms of size, it definitely isn't in terms of speed.

So, I think I will only optimize multiplication and division if the first number is a constant rather than if the first operation is a constant operation.  However, I will still optimize addition and subtraction both ways since you never have these problems with those operations becasue there's no speed loss from grouping individual operations.

This might take a while to re-code a bunch of routines to handle the new method, but I've already done the bulk of it and its turning out pretty good so far.

1448
The Axe Parser Project / Re: Features Wishlist
« on: May 25, 2010, 11:09:38 pm »
Yeah, interrupts will be very easy to use.  You simply enable them with fnOn, disable them with fnOff, and set them up with fnInt(label) and that subroutine will execute every interrupt.  Simple! There will probably be an optional second argument for interrupt frequency too.

The HARD part is how I am going to code them.  I need to make a vector jump table somewhere in ram which will reduce the size of one of the free ram locations by at least 256 bytes (more becasue it will have to start at a particular address).  I'm not sure which one, but it has to be very stable because if it gets modified at all during execution, it causes the program to sometimes randomly jump to some random code in the ram and its very difficult to debug.  That leaves me with the L1 pointer only which sucks becasue that is the largest continuous region for data storage that you can always use.  L2 loses MOS compatibility with interrupts and L3 means you can't use grayscale or the backbuffer.

1449
The Axe Parser Project / Re: Axe Parser
« on: May 25, 2010, 07:54:59 pm »
Hmm... I like the idea of having a command to return the VAT pointer, but it seems like it would be too low level to work with.  You would need to know all the equates to change the type for instance and know how that data structure looks in general to change anything.  Although it would be easy to add, I think it would just require too much assembly knowledge which is what I'm trying to avoid in this project.

If I ever do add it, it would be at the very end of the project where I just add a bunch of "undocumented" instructions (which actually are documented separately) but for assembly programmers who want to do some really low level stuff.

1450
The Axe Parser Project / Re: Axe Parser
« on: May 25, 2010, 04:43:02 pm »
Okay, I checked the doc again, and you're right, there is NO header at the variable's data.  There is only the size field.  All the header data is in the symbol table (and each header there is not a fixed size by the way).

1451
The Axe Parser Project / Re: Axe Parser
« on: May 25, 2010, 04:31:17 pm »
Oh yeah, I completely forgot about that!  I actually did add it, but don't use it becasue I forgot to make the arguments in order.  Its currently sortA(size,ptr) but I will change it to sortA(ptr,size) probably.  Or I don't know, which one do you think is more intuitive?

1452
The Axe Parser Project / Re: Axe Parser
« on: May 25, 2010, 04:22:09 pm »
It won't glitch on the Nspire or an emulator because they don't need the LCD delays.  But all the hardware is different and some LCD drives are slower than others and vary widely with different models.  Even my own calculator seems to have slightly different timing each time I use it based on the grayscale patterns I receive on what is usually perfect gray (possibly a temperature dependence?), so I would highly recommend switching into 6MHz mode during any grayscale displaying even if it works for your model.

EDIT: You should be able to read backwards into the header with a program or appvar header.  But if you're familiar with assembly, you'll know that the header data depends on the size of the program name and is in a weird backwards order I think (or is that the symbol table entry I'm thinking of).

1453
The Axe Parser Project / Re: Bug Reports
« on: May 25, 2010, 02:14:47 pm »
He's talking about the new error scrolling feature, not something wrong with the calculator.

It sounds like what's happening is that the program pointer is changing to a different location so its scrolling through garbage to the location of the error instead of the actual program.  I'll look around for something that might cause that, but I guess this feature is just temporary anyway until I have the real thing working.

1454
The Axe Parser Project / Re: Bug Reports
« on: May 25, 2010, 01:34:39 am »
When I press [PRGM] after an error, sometimes the program throws me into a giant jumble of jibberish. (Undoubtedly appearing because of the program being compiled.) Or is it something else...?

I can't seem to replicate this.  Can you give me an example of when this happens?  And on what type of error?

1455
The Axe Parser Project / Re: Axe Parser
« on: May 25, 2010, 12:32:12 am »
I haven't started working on it yet, but probably all the stuff I was going to do last week but didn't have time for.

Pages: 1 ... 95 96 [97] 98 99 ... 135