Page 2 of 2

Posted: Mon Jan 24, 2011 6:56 pm
by Gilbert
7-zip is a very, very good choice. As for ZIP, as far as I know the Windows internal feature is very, very crappy (the XP one at least) and it couldn't handle all ZIP files well, so you probably end up installing 7-zip or those WinXXX anyway.

Posted: Tue Jan 25, 2011 7:38 am
by Xious
cartlemmy wrote:
Shiru wrote:...it is because 7zip is better.
But sometimes 'better' doesn't matter when it doesn't have the most reach. If more people can access a .zip file than a .7z without downloading a new extraction tool then why not use .zip? Is using the 'best' compression tool worth alienating potential users of your software? Perhaps 7zip is more common that I think, in that case I my point is moot. Sorry for the rant, it is just something that befuddles me.
Think of it this way, it could be a SIT, LHA or GZ file. I think 7z is overrated especially for tiny data archives, but it's become the defacto standard for ROM distribution, so you may want to just break down and install the decompression tool. :)

Posted: Tue Jan 25, 2011 9:15 am
by cartlemmy
Xious wrote:...but it's become the defacto standard for ROM distribution.
That is a good reason to install it, and exactly the kind of input I was look for. I will keep that in mind when I post stuff up. I think I will post my stuff in .7z, .zip, and heck even my own favorite .tar.gz then let people choose which to download :)

And sorry for hijacking this thread, I brok down and installed 7z (which was quick and painless in Ubuntu) so I could try the rom. It's pretty darn cool, I really like the segmented animation.

Posted: Tue Jan 25, 2011 11:49 am
by tepples
A WINRAR IS YOU? No, a 7-Zip is you.*
cartlemmy wrote:If more people can access a .zip file than a .7z without downloading a new extraction tool then why not use .zip?
Zip always compresses each file individually, while 7z is more efficient when files are similar. If you have five files, all of which are nearly identical, then 7z can take advantage of redundancy between files. For example, NTSC and PAL versions of a game will usually differ little.

And think about it this way: more people can access a retraux PC game for Windows (e.g. Eversion, La-Mulana, Cave Story) using only software that comes with a PC than an NES game. More people have Windows, Mac OS X + Wine, or Linux + Wine than have Windows + an NES emulator, Mac OS X + an NES emulator, or Linux + an NES emulator. This is especially true considering that Fedora ships Wine but refuses to ship any NES emulators out of fear of Nintendo v. Red Hat.

As for .gz, most GUI tools that can handle .zip can handle .gz. Surely every tool on Mac OS X, Ubuntu, and everything not made by Microsoft can.


* See this ED article for context. Offtopic: does anyone sell the oversized orange newsboy cap like the one Tommy Himi wears?

Posted: Wed Jan 26, 2011 8:10 pm
by zlash
I'm really sorry about the 7z issue but I use it for all my packaging needs as its free, good, and has a non bloated tool that can open almost anything I throw at it.

And because I like it, I will keep on using it for the following uploads. :)

And now, another update:

Now the player code can also animate the tile indexes of the sprites, so now nicer animations can be built.

I updated the walk cycle animation to reflect the new changes.

http://www.zlashstudios.com/files/clarine_test_2.7z

Posted: Wed Jan 26, 2011 8:19 pm
by clueless
The mech looks a bit odd when told to walk and and forth for short distances.

That is, make it walk to the right 8 pixels. Then push left for 8 pixels. The screen will scroll back to the left a little, but the mech's leg motion will still be as if its walking to the right.

Posted: Wed Jan 26, 2011 8:24 pm
by tokumaru
The walking does indeed look better, but the legs look really weird when it first gets up.

Posted: Wed Jan 26, 2011 8:28 pm
by zlash
As the animation is only played forwards, it should not be able to move backwards (when you move to the left, the forward animation continues to play). That's why it looks that its doing some kind of moonwalk when you continuously move it to the left. That problem should not exist when I correctly play the animation backwards when walking to the left, but playing the animation backwards is not currently supported.

Posted: Wed Jan 26, 2011 8:31 pm
by zlash
tokumaru wrote:The walking does indeed look better, but the legs look really weird when it first gets up.
Yes, I should have added that as I changed the tile data layout I broke the standing up animation, and because the animation format changed I have to do the stand-up animation again, so I didn't bothered to fix it. :)

Posted: Wed Jan 26, 2011 10:19 pm
by Gilbert
I'm not sure whether I like the new version. While the cockpit is now animated, the turning looks a bit too choppy in action. Personally I prefer the non-animated one in the previous version. Maybe if 1. there are more frames to the animation (sacrificing more CHR space), or 2. have the mecha move/animate faster, or 3. have the cockpit bog up and down by one or two pixels during the animation it could look really nice.

Posted: Wed Jan 26, 2011 10:29 pm
by clueless
I also think that the cockpit should move up+down a few pixels while the mech moves. Seems more realistic.

You mentioned that you're developing an animation tool.

What does it output? Asm code, binary data or something in-between?

What kind of data does it hold in memory (sprite lists, connection points, hit-boxes, etc... )?

What platform does it run on (pc, mac, bsd, linux, solaris)?

What language did you implement it in?

Posted: Wed Jan 26, 2011 10:48 pm
by zlash
Thanks for your opinions! I will try to make it more natural as the game development progresses.

The tool outputs a binary file that holds timestamps and interpolation values for the keyframes of the animation.

The structure in RAM which hold the current values for each sprite uses 2 bytes + 15 bytes per sprite used on the animation.

The ROM data as you might guess, its a lot bigger. For example the stand-up animation uses 259 bytes and the walking cycle needs 429 bytes.

Im doing the program in C++ using GTK+, so it should be easily compiled for every platform where GTK+ is available (I tried it on Windows and Fedora)

But its still very fragile, and a lot of the GUI options are not working, so I want to wait its just a little bit more ready before releasing it.

Posted: Thu Jan 27, 2011 6:19 am
by clueless
Screenies! We (or at least, I) want screen shots! Even to a work in progress.

Does your tool handle Spherical Linear Interpolation or anything that oscilates along the path of a curve?

Posted: Wed Feb 02, 2011 9:34 pm
by bigjt_2
I'm coming into this thread pretty late so this is probably way off topic (trying to comb through and catch up on all the stuff I haven't had time to read in forever).

Anyway, I just wanted to say I tried out the ROM and LOVE the animation! That is solid as hell! Is the mech going to be able to jump? I guess I should ask what genre the game will end up being--I'm guessing platformer?

Posted: Fri Feb 04, 2011 11:36 pm
by zlash
For now, it only uses linear interpolation between keyframes.

Screenshot:
Image

About the genre, I'm still not sure about what it will end up being.