| |
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! |
|
| |
Scout
Registered: Dec 2002 Posts: 1570 |
Goodmorning.
7up Sprite Editor V2.0 might be interesting to look at.
Haven't got any actual experience with it but it might work for you.
Otherwise coding a small converter (in basic for example) is another option. |
| |
JackAsser
Registered: Jun 2002 Posts: 2014 |
Just a silly notion Rambo, 48x48 requiers 6 sprites. Anyway graham has this native program that converts most into most. Check his profile and see if u can find it. |
| |
Graham Account closed
Registered: Dec 2002 Posts: 990 |
GFX Transformer ofcourse :) |
| |
Ninja
Registered: Jan 2002 Posts: 411 |
If you are not afraid of C-sources, you can also check the C64-Tools from Cadaver's site. Or ask me. Or the usual suspects :) |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Quote: Just a silly notion Rambo, 48x48 requiers 6 sprites. Anyway graham has this native program that converts most into most. Check his profile and see if u can find it.
shit, thats 312 sprites!
oh well, i guess i can skip some frames.. :) |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Quote: GFX Transformer ofcourse :)
Using this, there remains the problem that the koala pics also have to be scaled down to fit into sprites.. |
| |
Graham Account closed
Registered: Dec 2002 Posts: 990 |
Do it yourself (tm) |
| |
Mirage
Registered: Jan 2003 Posts: 113 |
(Shameless plug)
Timanthes does sprite animations - You need one empty layer with the correct dimensions (48x63 in your case) that acts as a background and then add each new frame as a new layer (and flag all those layers as sprite layers)
If you want to see the animation run you will also have to add frames to the frames window and for each frame turn the relevant layers' visibility on or off.
On export timanthes will write out all the layers as one big sprite-data-block |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Ok Mirage..
But i have never managed to save anything with timanthes, it always bugs on save coz of supposedly wrong dimensions or something..
I now have the bmp files in correct size: 48x42, so i tried them in 7up sprite ed, but it 1) switches d025/d027, even in single color mode, and 2) only way to get sprites is as asm, and it makes sprite 1+4 completely $AA, even when they have a bitpattern (content).. so this prog is defunct!
I will try to import in timanthes, and if i cant make it work in some days, i will try and send you the bmp files.. :) |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
if it does not work try the native heigh-ho converter. |
| |
Devia
Registered: Oct 2004 Posts: 401 |
Quote: Using this, there remains the problem that the koala pics also have to be scaled down to fit into sprites..
You can stuff more sprites into one pic and use GFX Trans' Sprite Grabber function to save out individual sprite images.
|
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
its ok.. i converted the bmp files to correct size/color with thumbs plus, and imported them to timanthes.
still not finished.. |
| |
Wile Coyote Account closed
Registered: Mar 2004 Posts: 646 |
You could always convert your Koala images to Vidcom 64 images. Then load each image into Vidcom 64 and use the Vidcom 64 option of selecting any area of screen to convert to sprite(s).
Vidcom 64
Vidcom 64 |
| |
SIDWAVE Account closed
Registered: Apr 2002 Posts: 2238 |
Uh :) i havent used Vidcom since 1988 haha
Anyhow, thanks to all for your help!
Seems Timanthes is the tool for this job, because it can load images that are 2x2 sprites, and convert them.. |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
If you are using Kick Assembler it's rather easy to code a converter directly in the assembler source. Here is a little macro that converts a gif to a sprite. you can easily extend it to do 2x2 sprites or whatever format you like. I don't think it gets any simpler than this..
.pc = $3000 "Sprite Data"
spriteData:
:LoadSpriteFromPicture("sprite1.gif")
:LoadSpriteFromPicture("sprite2.gif")
:LoadSpriteFromPicture("sprite3.gif")
// etc
.macro LoadSpriteFromPicture(filename) {
.var picture = LoadPicture(filename, List().add($000000, $ffffff,$6c6c6c,$959595))
.for (var y=0; y<21; y++)
.for (var x=0; x<3; x++)
.byte picture.getMulticolorByte(x,y)
.byte 0
}
|
| |
LOGAN Account closed
Registered: Aug 2003 Posts: 71 |
Was also about to suggest kickass as kickassembler you can script so you are able to convert images to sprites, bitmaps, charsets and thats soooo cool :) |
| |
WVL
Registered: Mar 2002 Posts: 902 |
Quote: If you are using Kick Assembler it's rather easy to code a converter directly in the assembler source. Here is a little macro that converts a gif to a sprite. you can easily extend it to do 2x2 sprites or whatever format you like. I don't think it gets any simpler than this..
.pc = $3000 "Sprite Data"
spriteData:
:LoadSpriteFromPicture("sprite1.gif")
:LoadSpriteFromPicture("sprite2.gif")
:LoadSpriteFromPicture("sprite3.gif")
// etc
.macro LoadSpriteFromPicture(filename) {
.var picture = LoadPicture(filename, List().add($000000, $ffffff,$6c6c6c,$959595))
.for (var y=0; y<21; y++)
.for (var x=0; x<3; x++)
.byte picture.getMulticolorByte(x,y)
.byte 0
}
wat.
I never realized Kickass was *that* powerful.. /me drools |
| |
Mace
Registered: May 2002 Posts: 1799 |
Holy crap.
What WVL says! |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
Quote: Holy crap.
What WVL says!
what mace said |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
Quote: Was also about to suggest kickass as kickassembler you can script so you are able to convert images to sprites, bitmaps, charsets and thats soooo cool :)
I dont get it, how can you extend this code to work for say 2x3 spritebank setup per GIF picture?
I got a list of 13x GIF pictures in format 24x63 pixels each which fits the 2x3 sprite setup, but I have no clue how to modify that code in order to export the GIFs into that kind of template.
Anyone care to modify the code so it would work for my needs, and possible also better explain how to do that trick for more users here on csdb? |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
this might work
.macro LoadSpritesFromPicture( filename,
xsize, ysize,
bgcolor, color0, color1, color2 ) {
.var picture = LoadPicture( filename, List().add(bgcolor, color0, color1, color2) )
.for (var ysprite = 0; ysprite < ysize; ysprite++) {
.for (var xsprite = 0; xsprite < xsize; xsprite++) {
.for (var i = 0; i < [3 * 21]; i++) {
.byte picture.getMulticolorByte(
[[xsprite * 3] + mod(i,21)],
[[ysprite * 21] + floor(i / 3)]
)
}
.byte 0
}
}
} |
| |
enthusi
Registered: May 2004 Posts: 677 |
http://www.codebase64.org/doku.php?id=base:sprite_converter
Personally I prefer the assembler doing the assembling and tools acting as tool ;-) |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
@Burglar, it almost worked. One error only;
parsing
flex pass 1
.for (var ysprite = 0; ysprite < ysize; ysprite++) {
.for (var xsprite = 0; xsprite < xsize; xsprite++) {
.for (var i = 0; i < [3 * 21]; i++) {
.byte picture.getMulticolorByte(
^
Error: byte x coordinate out of range : 3
Maybe you see what to correct? |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
your image.gif is too small in width, u need to double it.
multicolor pixels are 2 pixels wide, so 2x3 sprites should be:
2 * 3 * 8 pixels wide = 48
3 * 21 pixels high = 63 |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
Quote: http://www.codebase64.org/doku.php?id=base:sprite_converter
Personally I prefer the assembler doing the assembling and tools acting as tool ;-)
so, where's your multicolor tool? ;) |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Shouldn't it be mod(i,3)?
|
| |
Magnar
Registered: Aug 2009 Posts: 61 |
@Burglar, still not working. Now I am using a GIF file with 48x63 pixels, 4 colors.
Gives error:
flex pass 1
.for (var ysprite = 0; ysprite < ysize; ysprite++) {
.for (var xsprite = 0; xsprite < xsize; xsprite++) {
.for (var i = 0; i < [3 * 21]; i++) {
.byte picture.getMulticolorByte(
^
Error: byte x coordinate out of range : 6
Sourcecode:
.var bgcolor= $000000
.var color0 = $ffffff
.var color1 = $696259
.var color2 = $000000
.var xsize = 48
.var ysize = 63
.pc = $3000 "Sprite Data"
spriteData:
:LoadSpriteFromPicture("C:\anna_1.gif",xsize,ysize,bgcolor,color0,color1,color2 )
:LoadSpriteFromPicture("C:\anna_2.gif",xsize,ysize,bgcolor,color0,color1,color2 )
.macro LoadSpriteFromPicture( filename,
xsize, ysize,
bgcolor, color0, color1, color2 ) {
.var picture = LoadPicture( filename, List().add(bgcolor, color0, color1, color2) )
.for (var ysprite = 0; ysprite < ysize; ysprite++) {
.for (var xsprite = 0; xsprite < xsize; xsprite++) {
.for (var i = 0; i < [3 * 21]; i++) {
.byte picture.getMulticolorByte(
[[xsprite * 3] + mod(i,21)],
[[ysprite * 21] + floor(i / 3)]
)
}
.byte 0
}
}
} |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
.var xsize = 2
.var ysize = 3
xsize/ysize is in sprites, not pixels. |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
Unfortunately same error even after changing the xsize and ysize values. |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Give my previous comment a chance :) |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
Got it to work by using lots of "for" statements.
However, the coloring is totally wrong. I would expect the LoadPicture with the list of added color values to be a search pattern through the GIF file and then arrange the multicolor byte in return according the order of the color array input.
Say, in the GIF; if I have $ff0000 as background, and I specify bgcolor=$ff0000 as first value, I would expect it to come into the sprite as the first value.
Now, it isn't and also it doesnt take all colors into consideration either. I lose the 3rd color in the convert process somehow.. Anyone? :)
Source:
.macro LoadSpriteFromPicture( filename, bgcolor, color0, color1, color2 ) {
.var picture = LoadPicture( filename, List().add(bgcolor, color0, color1, color2 ) )
.for (var y = 0; y <21; y++){
.for (var x = 0; x <3; x++){
.byte picture.getMulticolorByte(x,y)
}
}
.for (var y = 0; y <21; y++){
.for (var x = 3; x <6; x++){
.byte picture.getMulticolorByte(x,y)
}
}
.for (var y = 22; y <42; y++){
.for (var x = 0; x <3; x++){
.byte picture.getMulticolorByte(x,y)
}
}
.for (var y = 22; y <42; y++){
.for (var x = 3; x <6; x++){
.byte picture.getMulticolorByte(x,y)
}
}
.for (var y = 42; y <63; y++){
.for (var x = 0; x <3; x++){
.byte picture.getMulticolorByte(x,y)
}
}
.for (var y = 42; y <63; y++){
.for (var x = 3; x <6; x++){
.byte picture.getMulticolorByte(x,y)
}
} |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
argh yes, what cruzer said ;) (serves me right by using a too large png that wouldnt give errors anyway, doh facepalm)
|
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Finally someone listens :D |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
Guys, now you are both my heroes! :) I'll put down some serious greetz and credits to both of you for helping! THX!
|
| |
spider-j
Registered: Oct 2004 Posts: 498 |
Mh, this looks all too complicated for me. Should be easy to put this into two lines in a shell (or cmd if you are on windows).
1. Crop sprites from source bmp with ImageMagick
2. convert with bmp2sprite |
| |
Bitbreaker
Registered: Oct 2002 Posts: 508 |
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 :-) |
| |
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. |
| |
MagerValp
Registered: Dec 2001 Posts: 1078 |
ChristopherJam: there's a pure python png reader class out there so you don't have any external dependencies. I've then added a class to handle layers of tiled graphics with color restrictions, that spits out bitmap data. Works like a charm. |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
@Burglar: Yes please, maybe I can finally be 1337 then :) |
| |
Slammer
Registered: Feb 2004 Posts: 416 |
An alternative to makefiles is ANT, which is kind of advanced makefiles. It is good for platform independent development and can do advanced stuff like zip and ftp. The drawback is the xml-syntax.
If you are new to, or unsure of, the concept of making the execution of a program dependant on the change in another file, then start with makefiles (Simpler and easier to learn). If you need to make bigger and more advanced or platform independent build tools, then ANT is the way to go.
Traditionally makefiles is a C/C++ tool, while ANT is a Java tool, so if you use one of these languages, you might want to chose the matching 'build-language' since your standard tools probably already supports it. |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
I added the final version of the source to codebase64. Feel free to improve ;)
|
| |
Frantic
Registered: Mar 2003 Posts: 1648 |
Quoting BurglarI was thinking about writing a Makefile howto for codebase... Seems its needed for some people ;)
@Burglar: Please do! I certainly agree that some people would benefit from getting over that threshold, which is really quite low, considering that makefiles don't have to be complicated at all to be useful.
I've used makefiles for my C64 coding for quite a number of years now and using .bat/shell-scripts would of course be unthinkable. :)
Here is a quite generic little makefile that I found lying around on my harddrive. Maybe it can serve as inspiration or something... Of course it could be put in a simpler and more pedagogical way for someone who never used makefiles before, and it is not the optimal way of doing stuff in all cases there.. may even be some obsolete/erroneous lines in there.. but still.. just throwing it out here.. Maybe it helps someone.
"make" will result in the creation of a .d64 file with the assembled and crunched prg on it.
"make vice" will do the same thing, but also load the d64 with vice.
# Generic 6510 assembler makefile -- FTC/HT
#
# Assumes that all files named .a, .s, i., .inc., .asm are to be considered source files
#Project specific settings
NAME = template
STARTADRESS = 0800
STARTFILE = start.inc
POSTFIX = #.exe
# Names of main files and directories
TARGETDIR = bin
SRCNAME = code.a
PRGNAME = $(NAME).prg
D64NAME = $(NAME).d64
LABFILE = _vicelabels.txt
VICEOUT = _viceoutput.txt
# Generate a comprehensive source file list
SOURCEFILES =
SOURCEFILES += $(wildcard *.a)
SOURCEFILES += $(wildcard *.asm)
SOURCEFILES += $(wildcard *.i)
SOURCEFILES += $(wildcard *.inc)
SOURCEFILES += $(wildcard *.s)
SOURCEFILES += $(wildcard *.src)
# Tool locations
TOOLDIR = ~/sys/c64/devtools_mac
#TOOLDIR = ../_win32tools
#TOOLDIR = ../amigatools
# Specific tool locations
ACME = $(TOOLDIR)/acme/acme$(POSTFIX)
PUCRUNCH = $(TOOLDIR)/pucrunch/pucrunch$(POSTFIX)
EXOMIZER = $(TOOLDIR)/exomizer/exomizer$(POSTFIX)
C1541 = $(TOOLDIR)/vice/tools/c1541$(POSTFIX)
VICE = $(TOOLDIR)/vice/tools/x64$(POSTFIX)
#---------------------------------------------------------
# Create a .d64 with the prg on it
$(TARGETDIR)/$(D64NAME) : $(TARGETDIR) $(TARGETDIR)/$(PRGNAME)
@echo "*************************"
@echo "* Creating .d64... *"
@echo " "
@$(C1541) -format $(NAME),ht d64 $(TARGETDIR)/$(D64NAME) -attach $(TARGETDIR)/$(D64NAME) -write $(TARGETDIR)/$(PRGNAME) $(NAME)
@echo " "
#---------------------------------------------------------
# Assemble and crunch .prg file
$(TARGETDIR)/$(PRGNAME) : $(TARGETDIR) $(SRCNAME) $(SOURCEFILES) Makefile
@echo " "
@echo "*************************"
@echo "* Assembling program... *"
@echo " "
@echo " * = $$""$(STARTADRESS)" > $(STARTFILE) #Generate start adress file, included first in the sourcefiles
@echo " "
@$(ACME) -v2 --cpu 6510 -f CBM --vicelabeldump $(LABFILE) -o $(TARGETDIR)/$(PRGNAME) $(SRCNAME)
@echo " "
@echo "*************************"
@echo "* Crunching program... *"
@echo " "
@$(EXOMIZER) sfx 0x$(STARTADRESS) -m500 -p1 -x1 -p1 -t64 -o $(TARGETDIR)/$(PRGNAME) $(TARGETDIR)/$(PRGNAME) # > /dev/null
# @$(PUCRUNCH) -c64 -x0x$(STARTADRESS) -i0 -g0x35 -ffast $(TARGETDIR)/$(PRGNAME) $(TARGETDIR)/$(PRGNAME) > /dev/null
@echo " "
#---------------------------------------------------------
# Create TARGETDIR directory if it doesn't exist
$(TARGETDIR) :
@test -d "$(TARGETDIR)" || mkdir -p "$(TARGETDIR)"
#---------------------------------------------------------
# Open .prg file in VICE
vice : $(TARGETDIR)/$(D64NAME)
@echo "*************************"
@echo "* Open .d64 in vice... *"
@echo " "
@$(VICE) -truedrive +cart -autostart-handle-tde -moncommands $(LABFILE) $(TARGETDIR)/$(D64NAME) >>$(VICEOUT) 2>&1 &&
@echo " "
#---------------------------------------------------------
clean :
@echo "*************************"
@echo "* Cleaning... *"
@echo " "
$(RM) -f $(STARTFILE)
$(RM) -f $(TARGETDIR)/$(PRGNAME)
$(RM) -f $(TARGETDIR)/$(D64NAME)
$(RM) -f _*.txt
rmdir $(TARGETDIR)
@echo " "
|
| |
HCL
Registered: Feb 2003 Posts: 728 |
@Frantic: So that was supposed to be "not complicated at all"!?!? Any makefile larger than 10 lines is complicated :P. |
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
Quote: @Frantic: So that was supposed to be "not complicated at all"!?!? Any makefile larger than 10 lines is complicated :P.
+1
Make is scary. I have only used it once so far: While it adds flexiblity and saves compile time on the other hand it adds an extra level of frustration. Fighting with it is not fun, so it will do what you want. If you're not familiar with it, and you only started to use it for your c64 project you will have trouble. |
| |
enthusi
Registered: May 2004 Posts: 677 |
Nah. You can make super plain Makefiles that look and act like a mere bash script.
THEN you can add ONE layer of complexity by adding dependencies, etc.
super-easy to learn, hard to master though. But for big gain in c64 projects you'd hardly have to master it.
it breaks down to:
game.prg: game.asm leveldata.bin
xa game.asm -o game.prg
leveldata.bin: level.asm charset.bin
xa level.asm -o leveldata.bin
charset.bin: charset.koala
convert charset.koala charset,bin
this has 3 'layers' already. Yet leveldata.bin will only be reassembled when level.asm or charset changed. It will automatically recognize if charset.koala changed even though level.asm might still be the same etc.
You can hardly call this complex. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
"Make is scary."
you know what is _really_ scary? - supposedly decent coders proposing .bat files. /o\
not using make because it is "scary" or "hard" is pretty much like using basic over assembly because asm is "scary" and "hard". it boils down to "i am to lazy to learn it so i will pretend i dont need it". |
| |
Cruzer
Registered: Dec 2001 Posts: 1048 |
Agree with Oswald. I'm using Ant and Maven enough at work to get my need for boring configuration crap covered. When coding c64 I just want it to be fun and about hacking the c64. Will probably try out make someday though. |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
heh, gimme a few days to write the tutorial guys, but here are the simple most important rules:
JAVA=java
KA=-jar src/lib/KickAss-3.25.jar
KAFLAGS=-showmem -aom -symbolfile -afo -time
EXO=exomizer
EXOFAST=-m 4096 -p 1
EXOFLAGS=level -c -q $(EXOFAST)
EXOSFXFLAGS=sfx 0x1000 -n -q -D i_line_number=2013 $(EXOFAST)
%.prg: %.s
$(JAVA) $(KA) $(KAFLAGS) $< -o $@
%.prg.exo: %.prg
$(EXO) $(EXOFLAGS) $< -o $@
%.sfx.exo: %.prg
$(EXO) $(EXOSFXFLAGS) $< -o $@
and now you can just put bla.s in the same dir and type
unpacked:
make bla.prg
levelpacked:
make bla.prg.exo
selfextracting packed:
make bla.sfx.exo
|
| |
Oswald
Registered: Apr 2002 Posts: 5094 |
Quote: Agree with Oswald. I'm using Ant and Maven enough at work to get my need for boring configuration crap covered. When coding c64 I just want it to be fun and about hacking the c64. Will probably try out make someday though.
edit: wanted to quote this:
"not using make because it is "scary" or "hard" is pretty much like using basic over assembly because asm is "scary" and "hard". it boils down to "i am to lazy to learn it so i will pretend i dont need it"."
basically that's me :)
I've been still using profi assembler when friends already had tass, and been coding on c64 when emulators were already good enough, and been coding in emulators when I should have been cross asming :) Now I'm here crossing (but denying to use anything more advanced than 64tass:), and promise I'll use 'make' too when I'll need to link again, but I really hate jumping through the firey loops of all the syntax shit whenever it comes to a new language/scripting/make whatever. It always takes a lot of time swearing and frustration. I hate that shit. :) |
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
Quote:gimme a few days to write the tutorial guys, but here are the simple most important rules:
hihi. this kind of "example" is what scares people away from makefiles IMHO (it was like that for me, that much i know =)). ie, dont start with something that uses tons of features at once, you dont need variables or implicit rules to get it going =) once you understand the very basic principle
target: ingredience
commands
...you can go from that and write more complicated stuff (your example will already give people a headache in cases of "i want to compile this source with different KAFLAGS")
copypasting someone elses makefile "that contains the important rules" without understanding it completely is about as bad as copypasting a kickass macro for sprite conversion without knowing exactly what it does - imho :)
|
| |
chatGPZ
Registered: Dec 2001 Posts: 11386 |
"basically that's me :)"
you know what? EVERYONE knows that, since ninjas talk =D |
| |
Pantaloon
Registered: Aug 2003 Posts: 124 |
That so 1990 to use make or ant :) I have my own build system that works like a charm. Only supported on Windows tho but i'm totally stuck to this platform :) Basically it's a visual basic script (where the wm is available on all windows os's since 1995) and is alot more powerfult hen batch files.
I can simply define dependencies like this
addSourceFile "Source/Fx/Staircase/Staircase.s", "Source/DemoSystem.s, Source/SomeStuff.s", "10.FAIRLIGHT", -1
I can add any file with dependancies to anything, like out of date.
It compiles/links and builds disk image(s) and outputs hashtables of all sectors/tracks so it can be used in lookupfunctions in kickasm. (useful when you actually use t/s for laoding).
It uses a 2 pass build so any changes can be detected in the second pass aswell.
The idea is that if i want something to build differently i can easily just script it, instead of relying on how ANT/Makefiles treat dependancies.
But i do agree, a make system is never bad :)
|
| |
Radiant
Registered: Sep 2004 Posts: 639 |
Declarative build systems have their definite drawbacks, yes - I can't even begin to count all the ugly hacks I've had to do when using Ant and Make and their completely dependency based flow. Ultimately I think Make in particular works very well for C64 development though, especially when coupled with a Unix-y toolchain such as cc65.
If you're into fancy-schmancy modern build systems do have a look at Gradle, CMake and Maven apart from Ant; you might find one of them more to your liking. |
| |
Burglar
Registered: Dec 2004 Posts: 1101 |
Quoting GroepazQuote:gimme a few days to write the tutorial guys, but here are the simple most important rules:
hihi. this kind of "example" is what scares people away from makefiles IMHO
Yea, sorry about that, but I wanted to counter the super scary and complicated Makefile Frantic posted ;)
Quoting Groepaz
target: ingredience
commands
and thats what it is exactly. but, like I said, I'll write a tutorial.
weekend just started, so it should be done before monday ;) |
| |
Frantic
Registered: Mar 2003 Posts: 1648 |
Well.. hehe.. The point with posting my makefile wasn't to serve as an introductory example really, as I did in fact write. That was what Burglar was supposed to come up with. :)
Sorry to scare you guys. Didn't know you were such tame lamers. ;) |
| |
Bitbreaker
Registered: Oct 2002 Posts: 508 |
This adds well to what Frantic said :-P
http://www.youtube.com/watch?v=0oRX1t0Crek |
| |
Magnar
Registered: Aug 2009 Posts: 61 |
Burglar made a new forum thread with makefiles etc in mind. So, please close discussion about that in this converting to sprite thread. :)
Cheers all, and again thnx for all inputs! been splendid reading |