| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Converting to sprites
Ok, so i have run into a problem.. hehe
I have 52 bmp pics, which are each the size of 2x2 C64 sprites.
So there's room for them all in 1 VIC bank..
Now problem is to convert them..
I tried Gang-Ed, but it only imports bmp as hires/mcol bitmap/char, and blows up the small image to fullscreen!
So i saved all the frames as a koala pr pic.. hahaha
Now i am stuck with 52 koala pics, that need to be transformed into 4 sprites each, bwahaha..
This is really silly..
What i really need is:
1) convert the 48x48 pixel bmp to 4 colors
2) convert this to 4 sprites
Is there an editor, where i can load bmp/gif into a sprite editor ? they have correct size, just need to be fixed to 4 cols.. which i can do with a batchconvert in thumbs plus (reduce nr of colors)
??
Thanks for any help! |
|
... 56 posts hidden. Click here to view all posts....
|
| |
Magnar
Registered: Aug 2009
Posts: 61 |
Quote: Gimp can export .spr as well. Also, somehow i don't get it why to introduce tools implemented as assembler-specific macros. A tool for all that is written in any language with a few lines of code in case. In my youth i drew sprites on quad paper and added the pixel values by mental arithmetic. Don't be such pussies and IDE-users :-)
First of all, thanks a lot to Burglar and Cruzer for nice and precise answers to the convert question I raised here in the "C64 Coding" forum.
As response to, "Also, somehow I don't get it why to introduce tools implemented as assembler-specific macros".
To me, just a few rows of code in Kickasm for converting GIFs to sprites was the most easy and spot on solution.
I know a little about programming languages, but I dont know a lot or all languages or how to operate tools others written in various operation systems (linux/windows), programming languages (java, c++, Python, Pearl etc) in order to tweak them to work in specific ways. Therefore, I am extremely grateful for the responses I got drilled down to something I can at least on a half-decent level understand and finally operate with results as success. :)
However, we all work in mysterious and different ways, which means that something that works for me might not work for you.
Peace! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
You're welcome, Magnar! About the "you're doing it wrong" discussion...
What I like about using an asm script:
- It's easy to change if your gfx needs to be located in some non-standard way that a tool doesn't support.
- It's easy to update the gfx. Just draw on the PNG and the gfx will be imported the next time you assemble the code.
- No need to install a tool for every purpose
What I don't like:
- Slow for heavy tasks
- Language is too simple for complex tasks
So for heavy/complex tasks I'm now using a Java plugin for KickAss. But yeah, the more ways of accomplishing something, the better I guess.
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
you're welcome magnar ;)
for me its pretty much the same as Cruzer. my Makefile has proper dependencies setup, so that I can just edit a png (or whatever) and run make.
and that's all I need to do to build a new d64, zero other steps required. and that speeds up my development process considerably.
but yes, using kickass to convert graphics on the fly is pretty slow (4-5 sec for a full bitmap pic), but since it only needs to do it once per picture it's fine really.
@spider, everybody should use what they like most and fits their needs. there is no 1 solution that is best in all cases.
but in magnar's case he'd have to copy/paste/save/convert 78 (3*2*13) times and then link the result, every time the graphics is updated. sounds like a mind-numbing chore to me ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"It's easy to update the gfx. Just draw on the PNG and the gfx will be imported the next time you assemble the code."
reading things like that scares me - ever heard of makefiles? /o\ |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I'm with Groepaz. Personally I code my converters and generators in Python and incorporate them into my build system - also helps keeping the business logic in the assembler separate from any compile time dependencies; and thus also prevents any expensive conversion/generation tasks from running except when really needed. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i have actually moved quite some converter shit from being done inline using kickass to using external tools during the process of making artphosis - because with external tools it is *much* faster. using the scripting for importing simple generic binaries (that have no tricky special format) is simply using the wrong tool for the job, imho.
that said, kickass is seriously lacking INCBIN =P |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
"ever heard of makefiles? /o\"
Yes, but not really used. I have called external tools from shell scripts/batch files if that counts. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
sorry, no - it is a common misconception that .bat (or shell scripts) files are even remotely similar to what makefiles can do (proper dependancies, only build what needs to be build because of changes) :) i seriously recommend anyone to look at it, because it WILL make your codinglife easier :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Hey @radiantx - nice to see a fellow Python user. And yes, it's sooo much more appropriate for coding image converters etc than trying to hack around with an assembler macro system, especially with the help of Numpy & PIL.
I agree with the people promoting proper use of Makefiles above, too. Some of the datafiles can take way too long to regenerate every time, but you also don't want to forget a step. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
I was thinking about writing a Makefile howto for codebase... Seems its needed for some people ;)
@radiantx, the language in which you write your tools is not that important. if a python script does the trick for you, great!
Personally I use perl for some things and kickass for others.
I just prefer to use kickass for gfx conversion, as it already has getSinglecolorByte and getMulticolorByte. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
