KermM wrote:
What's wrong with the compressor exe that is already included with spiffy?

It Does not accept command line arguments. This makes it totally unusable in the deployment method we have in mind. Which is every thing is organized into directory structures with easy filename conventions pictures are in a bmp format etc. Then on compile time it dynamically compresses and compiles all the assets needed.

and yes c++ is fine. Thank you Kerm!

If any one else is still willing to give it a go cause we all know Kerm has a lot of projects going let me know Razz

Thank you ^_^
Kerm has a lot of projects, but the biggest bottleneck at the moment is that Kerm has a lot of schoolwork. Smile I think a good thing to do might be to try to disassemble / decompile that executable and see if I can get anything else out of it. Feel free to keep nagging me. Smile
Hmm we have another question were looking for another good compression setup that can outperform spiffy (if we find one we would like to flip spiffy is the best we can find atm)

The guide lines are has to compress well decompress well
and preferably be able to compress data oncalc as well as off

Any suggestions?
You're always going to end up with a tradeoff between speed, size, and compression. For example, you can come up with something that gets great compression ratios, but requires a lot of code and a lot of scratch space to work. You can find a very simple and lightweight algorithm, but it won't get great ratios.
well after poking Dan in an Email (Dwedit) we got this

Dan Weiss / Dwedit wrote:
"Spiffy compression" is actually very bad. I'd gladly purge it from the face of the internet if I could.

Anyway, I'm just responding to let you know about a new compression method I've been trying out since then.

A while ago, I was reading a neat article about image data compression, this page suggests using prediction combined with bit-level RLE to compress images:
http://hbfs.wordpress.com/2009/04/14/ad-hoc-compression-methods-rle/

So I had implemented this compression method, I wanted to see how well it did. I had to modify this compression method for 1-bit images.

I used this test image:



The compression method works by creating a predicted image by looking at the current pixel, the pixel to the left, and the pixel above the current pixel.



After you make a predicted image, you can compress that, and it compresses better than a regular image.
After you decompress it, you need to also un-predict it back to a normal image.

The compression method used is RLE, when you see two of the same bit, it starts an RLE run, just like the algorithm described on that page.

The Bubble Bobble title screen there compresses to 601 bytes, which beats WinRAR by 36 bytes.

I've written a compressor in C#, but I haven't written any decompressors in Z80 yet. Are you interested in me writing one?
By the way, the compression method works much better on higher bit depths, like NES or Gameboy 2bpp images, because the predictor emits far more zeroes than anything else, and you can take advantage of that.

Good luck on your game!


Thats actually looking really promising i wonder what the requirements on calc would be though ram wise? More emailing away xD
Not much has progressed with CaDan, other than setting up just the basics to get the thing to run.

Why? I found out the hard way that one shouldn't put the stack pointer in the user RAM area ($9D95+) when unarchiving variables. For some reason, archiving them seems just fine, but unarchiving them causes problems for some reason.
Iambian wrote:
Not much has progressed with CaDan, other than setting up just the basics to get the thing to run.

Why? I found out the hard way that one shouldn't put the stack pointer in the user RAM area ($9D95+) when unarchiving variables. For some reason, archiving them seems just fine, but unarchiving them causes problems for some reason.
That's odd, and quite unexpected. I wouldn't be surprised at all if TI moves the stack pointer all over willy-nilly anyway. Actually, when you move the stack pointer, you stick it at the highest memory of some reserved memory like a program or appvar, not in empty space, right? If it was in empty space then the program being unarchived could happily overwrite it, but I'm sure that you thought of that.
KermMartian wrote:

[...]
That's odd, and quite unexpected. I wouldn't be surprised at all if TI moves the stack pointer all over willy-nilly anyway. Actually, when you move the stack pointer, you stick it at the highest memory of some reserved memory like a program or appvar, not in empty space, right? If it was in empty space then the program being unarchived could happily overwrite it, but I'm sure that you thought of that.

I placed the stack in an area that I've allocated using the insertmem romcall, but it does not belong to any variable. I do have reason to believe that the stack is being moved from underneath itself and whenever whatever routine TI is using tries to ret, it's not seeing the return address right there.

I don't think the insertmem thing is doing anything wrong. When I moved the stack pointer back to its old place ($FFxx), the problem doesn't occur, and the file that is unarchived is placed nowhere near the strip of memory I've allocated for the stack pointer, which means it's not overwritten at the end.

I suspect that the memory is modified while the unarchive process is being performed, but no one ever knows about it unless you've got SP there or you've got something running in that location... or you're trying to step through the routine (which is what I tried to do but got bored after 5 minutes)

Urk. I'm just rambling on, aren't I?
geekboy1011 wrote:
Thats actually looking really promising i wonder what the requirements on calc would be though ram wise? More emailing away xD

That's extremely similar to the Paeth predictor used in png compression. All you need when decompressing is the compressed data and a buffer to hold the decompressed data, it's just that as you decompress you then need to undo the filter by looking at previously decompressed pixels.

As far as that goes, it's basically png with filter type 4 but RLE instead of deflate compression.
Iambian wrote:
KermMartian wrote:

[...]
That's odd, and quite unexpected. I wouldn't be surprised at all if TI moves the stack pointer all over willy-nilly anyway. Actually, when you move the stack pointer, you stick it at the highest memory of some reserved memory like a program or appvar, not in empty space, right? If it was in empty space then the program being unarchived could happily overwrite it, but I'm sure that you thought of that.

I placed the stack in an area that I've allocated using the insertmem romcall, but it does not belong to any variable. I do have reason to believe that the stack is being moved from underneath itself and whenever whatever routine TI is using tries to ret, it's not seeing the return address right there.

I don't think the insertmem thing is doing anything wrong. When I moved the stack pointer back to its old place ($FFxx), the problem doesn't occur, and the file that is unarchived is placed nowhere near the strip of memory I've allocated for the stack pointer, which means it's not overwritten at the end.

I suspect that the memory is modified while the unarchive process is being performed, but no one ever knows about it unless you've got SP there or you've got something running in that location... or you're trying to step through the routine (which is what I tried to do but got bored after 5 minutes)

Urk. I'm just rambling on, aren't I?

Actually, TI-OS makes sure the stack is within a certain range when unlocking flash, to combat exploits.
It does? That's good to know. I was going to suggest that he might want to insertmem inside a known variable to avoid problems with the OS romping over memory it thinks is empty.
The text thinger works well enough.
Been working on the menu system, but I ran into things that I needed to take care of before that could happen, such as ways that graphics needed to be loaded and stuff like that. More information on that when I get done, but for now, here's a screenshot of what the text looks like in CaDan (large font). Tell me what you think.

The little t looks off a little because of that extra dot to the top left.
Iambian wrote:
With the reboot of CaDan comes a request for characters to star in the official rebuild. A total of eight playable characters is possible in the selection screen, though I'm going to have to slim it down to three if I can't get anyone to provide stuff. I'm also requesting bosses and their information, of which there will be 6 main bosses and 6 mini bosses. Though I don't have the sprites with me, I'm also requesting a 32x32 portrait sprite and mask (I'll fill in the details if you don't want to do that part), and a corresponding 8x8 game play sprite.

So far, I have three player characters. One serious and two jokes.

1. DevBlock - The unfortunate test character in almost every one of my games. First featured in Fishy, and often mistaken for a puzzle piece from another unrelated game, he gets thrown into the CaDan universe, where he's totally clueless, as usual. His script tells him to be annoyed at everyone and fight anyone for any reason, so that there will be conflict, even if unjustified. The first boss tells him this right then and there.

2. Netham45 (pre-lobsterification) - Completely unaware of the new environment. Won't move unless fully focused with the task at hand, and tends to give everything he's got once that focus is there. Strange things are flying at him, so his natural response is to blast 'em out of the sky. Takes the form of a spork.

3. Netham45 (post-lobsterification) - The future of Netham45, his temperament has changed dramatically after becoming a blue lobster and becoming the proud owner of his own FISHTANK CITY. The enemies all claim that he owes them payments on some sort of mortgage that doesn't exist. This Netham wants these guys to "Produce the Note" and prove once and for all that these guys are frauds and they have absolutely no claim to his city / 50-foot-tall-giant-fighting-robot. Lobster-y type attacks ensure the enemy's demise.

So far, I have one boss character:

1. 404 Boss Not Found - The placeholder boss for the series. A repeat occurrence until all boss and miniboss slots are filled. Each time it appears, it'll let the players in on some of the details about the environment all the player characters are trapped in, and discuss the fact that they NEED to fight to please the gods of CaDan. Always have flimsy as hell excuses for fighting, but at least they're more real than any other excuse other bosses can come up with. They ought to be.

-------------
So, let's get creative here. I understand that Geekboy has already gathered a bit of information for his own edition of CaDan. I'm not trying to compete with that, but I do have permission from him to copy over some assets. What I want is verification that the appropriate owner of those assets provide that permission as well.

Uh. Wow. That was a little long.


Cross post cause idk if iambian forgot about the topic here Razz
Got character select menu to work. You will not be able to select some characters, either because I haven't put them in yet, or they haven't been unlocked.
HOLY SH*T that looks more epic than I thought it would based on the description you gave me on irc.
Loving it!
What;s with the pentagram on the title screen? Shock That looks great, Iambian!
EDIT: The pentagram was something I whipped up for some sort of "cool" background for CaDan. Made completely in MS Paint.

Here's what I got so far for the high score screen. What I need to do now is to actually display the scores. I sense a lot of strife and debugging ahead of me...

Four scores are displayed at a time, using the smaller font. What do you think of the layout? Halfway decent? Think I should change it? If so, what should change? Should I add something else? If so, what? Lots of questions, and lots of hair pulling to do Razz

Looks more than halfway decent to me! I see nothing in particular that needs to change, other than nagging you to add Shaun and me as characters. Wink
I think I'm finished with the high score screen. It took a little more than I expected, yet a little less than I thought... if that makes any sense.

Changes: Other than the scoring, mostly alignment, and moved the sprite to the gray buffer.

Used a test situation to verify that the structure of the file is good and that access is consistent with my spec. That's what you're seeing in the score area. The "--EMPTY-" slots is how the file is originally formatted.



Did you like the character sprite better in the black buffer?

EDIT: Added in a character sprite background in the gray buffer. Tell me how that looks. Perhaps alignment can change? I mean, if I left-align it, it tends to make the text in front of the image difficult to read. I'm not sure where to put the gray 32x32 image.

  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement