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 ... 109 110 [111] 112 113 ... 135
1651
« on: April 23, 2010, 10:36:18 pm »
Yeah, that would be nice. I just have the omnimaga forums bookmarked and so its just a click away. Not sure how many people would actually type that out though, unless it was really really short like "axeparser.com" or something. But still, it would certainly look more official than the forum link.
1652
« on: April 23, 2010, 10:24:50 pm »
Reading from archive isn't really that tricky, but it would certainly make the code a lot bigger and require new commands. You can't just use a pointer; you have to switch pages, store data from that page to a register (temporary variable), switch pages back to the normal RAM, and then save the register into the RAM page at the desired location. You have to do this for EACH byte or two byte combination you read which means its a lot slower than reading directly from ram.
I think it would really complicate things a lot and it would be about the same speed to unarchive it anyway as it would be to read all of the bytes from archive, although it would definitely be faster for individual bytes. Putting the calculator in 15MHz mode during archive/unarchives is generally fast enough. Reading a 6000 byte map by unarchiving would take less than a second to unarchive and especially for RPGs, a little loading bar once in a while isn't that big of a deal since it would never be in the middle of game play. Just keep the data in ram until its no longer needed.
By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more. Then unarchive it before you quit.
1653
« on: April 23, 2010, 02:16:23 am »
Wow! That's a really neat effect! Good job.
I just happen to be writing the actual Line() routine right now. Its a lot harder than I thought it would be becasue I can't make more than one call or absolute jump in the assembly template unless I make some major modifications to the parser. It might have to be a "shell only" command until I finish writing a good one myself.
1654
« on: April 23, 2010, 01:12:13 am »
What the...
It probably won't last though. I remember Pyoro was ranked #1 for a little bit too.
1655
« on: April 22, 2010, 02:57:24 am »
I like http://www.shadyurl.com/ 
LOL!!! Thats hilarious! I'm so going to use that. 
1656
« on: April 21, 2010, 09:50:55 pm »
Exactly. That's what I was thinking of.
But don't get too used to it, there will be much easier and faster ways to do grayscale in the future.
1657
« on: April 21, 2010, 07:27:32 pm »
If your background is in Pic1, then just draw it to the backbuffer:
[Pic1]->Pic1
det(12)
conj(Pic1,L3,768)
It will appear gray behind your foreground. I haven't really added any grayscale drawing yet, so there is very limited usability right now. But I'm sure you can do tricks with exchanging the buffers.
1658
« on: April 21, 2010, 01:04:32 am »
Trust me, its getting downloads. This happened to a few of my other programs as well, so I'm not too surprised. I don't think missing stats imply that it lacks downloads, I think its something else or a fluke in the system. Every program gets downloads on the front page no matter how dull or boring it is. And when it has animated screen shots, its likely to get many. At a bare minimum, I did download it to double check the file after it got approved there.
1659
« on: April 21, 2010, 12:43:45 am »
No, its being downloaded, I've already been getting emails
1660
« on: April 20, 2010, 01:24:35 pm »
Reminds me of when I was making Pyoro. I fit the entire data structure for each fruit crammed into just 4 bytes, not a single bit was wasted. Not only that, I actually reused different parts of the bytes to represent different types of data depending on the state of the object.
1661
« on: April 20, 2010, 01:18:17 pm »
You can compress the size by storing to the nibble of the byte rather than using a separate byte for each entry in the array. 16 distinguishable masses would be more than enough I'm sure, and the other nibble can maybe be the sprite number or some other quantity that has 16 unique states or fewer. Same concept as the map compression, but with data.
1662
« on: April 20, 2010, 12:24:36 pm »
Question:
If you have fastCopy impemented, then why does CopyBuffer use GrBufCpy?
What is called "Fastcopy" in the routines is actually safe copy. Copybuffer was what I used to use but I don't use it anymore. I'm just keeping it there becasue in the future there will be more settings on how to optimize the code for efficiency on the size-speed spectrum. Not all the routines in the list are actually used.
1663
« on: April 20, 2010, 02:07:59 am »
In my case, in Opera/Firefox with Quigibo version I had Times New Roman as doc font but in IE it was something like Arial for some reasons. I did not have issues viewing the text, though. That's interesting because that's exactly the opposite of what happens to me. Most of the font is supposed to be Arial and all the commands are supposed to be Courier New, that's what Firefox and IE both show on my computer (vista and ubuntu). It might have something to do with the Unicode rather than the font, but its just temporary since it will all end up in the pdf eventually.
1664
« on: April 19, 2010, 11:46:35 pm »
I think you're mistaken. The 83+/84+ calculators all have 64KB of RAM. In fact some of them even have extra ram pages that extend the ram up to 128KB. By default, 64KB is available for reading and 32KB can be used for writing, but there are ways in assembly to extend read and write to the entire ram as well as most of the rom.
Edit: I think some people might consider the being able to read and write continuously to be what separates what is called "ram" and "rom" but I consider it ram since its partially accessible without needing to switch pages.
1665
« on: April 19, 2010, 10:40:01 pm »
I've decided to release the source code for all templated commands the compiler uses when parsing. I challenge anyone to improve the code You'll have to ignore the cryptic scripts that surround the routines and it probably won't be very obvious what is being done in each one of them. If you see any routine you think you can get from the start to the finish more efficiently with equal or lesser size, alert me! If you have any specific question just ask. Some of the inefficiencies I can't do anything about by the nature of the way the parser currently works, but I plan to correct this eventually (like the jr's at the beginning of the subroutines) This might also benefit anyone who is trying to transition from Axe to assembly since Axe is for the most part just cookie-cut out of this template.
Pages: 1 ... 109 110 [111] 112 113 ... 135
|
Show Posts