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 ... 112 113 [114] 115 116 ... 135
1696
TI Z80 / Re: A new (probably pretty bad too) OS
« on: April 13, 2010, 05:59:24 pm »
Did you ever release the OS program you made?

No, it got deleted in a RAM clear many years ago.  And the backup I had made was pretty outdated so I just gave up :(

1697
TI Z80 / Re: A new (probably pretty bad too) OS
« on: April 13, 2010, 05:23:56 pm »
Well, if I have the hex, I can package it as an app for you.
What would you do about the absolute jumps though?  If there was a jp $9D9A in the code you would have to remap it to jp $4005.  With only the hex code, you have to disassemble it and it would be pretty cumbersome to do.

I didn't know ion wasn't an app.  Hmm... now that I think about it, maybe it is possible, but what you would have to do is write some code to a safe ram area that is able to run the new program and then re-open the shell again after it returns.  Then you would have to jump to that location and hope that the client code doesn't write over that area.  All of that still requires a lot of inline ASM.

1698
The Axe Parser Project / Re: Bug Reports
« on: April 13, 2010, 05:15:20 pm »
Wait, what do you mean "by zero"?  Anytime you divide by zero the calculator is supposed to explode! (or return -1)

I'm already aware of that the current division routine is unsigned, and purposely so.  The signed division will come soon.  You can do signed division with the "//" operator in the future.

1699
TI Z80 / Re: A new (probably pretty bad too) OS
« on: April 13, 2010, 04:30:44 pm »
But all the app does is copy it to the ram and run it.  Just by the nature of how absolute jumping works, there's no way it could be converted to an app unless it was actually being emulated but I highly doubt that becasue then it would be unreasonably slow.

1700
TI Z80 / Re: A new (probably pretty bad too) OS
« on: April 13, 2010, 04:24:25 pm »
Hey, I wrote an OS in TI-BASIC one time with a start menu, games, notepad, paint, and some other stuff.  So its certainly possible.  But realistically, I don't think you'll be able to do program launching from a program since it would need to copy it over it's own code, destroying the shell.  It pretty much has to be an application to do that.  I like the idea though, there's still probably a lot you can do, certainly much more than BASIC.

1701
The Axe Parser Project / Re: The Axe Pages
« on: April 13, 2010, 04:08:30 pm »
Okay, I downloaded openoffice and I think I get the hang of it.  I'll post a list of articles that need to be written.  Don't feel pressured to write something you don't want to becasue I'm going to be writing whatevers left over anyway.  And I'll be rewriting or rewording the articles to make them transition between each section better so don't worry about that, its the core content that's most important.

If you want to do one, post your request here.  First post first pick to avoid duplicates:

  • What is Axe Parser?  What can/can't it do?  Advantages/Disadvantages Quigibo
  • How syntax looks/Differences with TI-BASIC Quigibo
  • How to use the Parser Quigibo
  • Numbers (hex vs decimal, signed vs unsigned, 1 byte vs 2 byte)
  • Labels, Subroutines, and program flow.  Order of operations.
  • Pointers 101 What are they? How do they work?
  • Data, Memory, how to read and write to them.  Making sprites/strings/maps.
  • Reading/Writing/and creating Save Files.  How to archive/unarchive
  • How to optimize/neat tricks.
  • Writing a simple game: A tutorial. SirCmpwn

Plus there are the Individual commands.  Each one should have 1 or 2 examples and a short paragraph sized explanation.  Some commands might need more or less though depending on how complicated they are.  I'll put the list of done commands right after this:

N/A

I have to write the "Using the parser" one becasue its changing next version with new options like shell support.  When you finish one, just upload it here as an attachment.

1702
The Axe Parser Project / Re: Features Wishlist
« on: April 13, 2010, 03:22:51 pm »
Raycasting wouldn't use the Line() command unless all the walls are pitch black, and then you can't see anything.  The actual algorithm is very complicated and although it could be made with Axe, it would either be too slow or very minimal.  However, by using Line() Axe is definitely fast enough for some realtime 3D wireframe renderings.

I won't promise anything, but it could be a possibility that I might add automated ray casting and mode 9 support in a very far future version.  I have no idea how it would work though.

1703
Axe / Re: Turn order based on value in AppVar?
« on: April 13, 2010, 03:10:56 pm »
Everywhere in that sample where you used "B" just replace it with "L1".

1704
The Axe Parser Project / Re: Bug Reports
« on: April 13, 2010, 02:49:43 am »
Uuugggg....

I just noticed that the grayscale command is not working.  It worked fine on wabbit, but it fails on actually hardware.  Its too fast for the LCD drivers, and on Full speed mode its even worse.  I thought becasue it was grayscale that extra code would give it that time delay it needs, but damn that LCD driver is slow!  I have one of the newer 84s by the way with the slower driver.  I think the only reason Pyoro worked in gray was that I had a triple buffer, which was just slow enough for the delay.

I'll have it fixed next version.

1705
Axe / Re: Turn order based on value in AppVar?
« on: April 12, 2010, 11:21:13 pm »
That definitely shouldn't cause a RAM clear.  What is the other code you put around it?

1706
Portal X / Re: Portal X
« on: April 12, 2010, 11:18:45 pm »
I sent you an email with optimizations using some math tricks for your collision detection.  Should be a little faster.

The other thing I was talking about, I'm still not sure exactly what method you're using for collision detection.  Why does the character need more points checked than the boxes?

1707
The Axe Parser Project / Re: Bug Reports
« on: April 12, 2010, 10:30:42 pm »
Originally, it was unintentional, but it produces the smallest code.  It could return the answer, but then it adds an extra byte or 2 every time you store to a pointer.  Both ways have advantages in optimization.

You can optimize this:

A->{L1}
B->{L1+1}
C->{L1+2}

like this:

C->{B->{A->{L1}+1}+1}

So don't think that its a bad thing it returns the pointer, there are some good things you can do with it.

1708
Portal X / Re: Portal X
« on: April 12, 2010, 10:25:59 pm »
Wouldn't you only need to detect 4 directions each frame for each object?  If you're detecting more than once per frame, then you can save those cycles with a compensation by detecting how far past the collision the object is when it collides.  Then just snap it to where the collision was supposed to happen.

1709
Portal X / Re: Portal X
« on: April 12, 2010, 03:16:21 pm »
What are you doing exactly that requires so much speed?  Maybe its the method you're using that can be optimized.

1710
The Axe Parser Project / Re: Features Wishlist
« on: April 12, 2010, 02:44:41 pm »
Yeah, but its much more size and speed efficient to use bit checks.  I'll add auto-ops for "and" and "or" operations with powers of 2 sometime in the future so they can be used.  Maybe even a binary prefix, becasue that would really help with this.

EDIT: ninja'd!

Pages: 1 ... 112 113 [114] 115 116 ... 135