Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Converting to sprites
2009-07-02 04:33
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!
2009-07-02 04:57
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.
2009-07-02 06:34
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.
2009-07-02 07:12
Graham
Account closed

Registered: Dec 2002
Posts: 990
GFX Transformer ofcourse :)
2009-07-02 09:13
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 :)
2009-07-02 11:09
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.. :)
2009-07-02 11:12
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..
2009-07-02 11:17
Graham
Account closed

Registered: Dec 2002
Posts: 990
Do it yourself (tm)
2009-07-02 11:18
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
2009-07-02 12:49
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.. :)
2009-07-02 13:17
Oswald

Registered: Apr 2002
Posts: 5094
if it does not work try the native heigh-ho converter.
2009-07-02 13:32
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.
2009-07-02 15:57
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..
2009-07-02 17:37
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
2009-07-02 18:49
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..
2009-07-02 20:36
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
}


2009-07-03 03:51
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 :)
2009-07-03 08:59
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
2009-07-03 11:43
Mace

Registered: May 2002
Posts: 1799
Holy crap.
What WVL says!
2009-07-03 13:09
Oswald

Registered: Apr 2002
Posts: 5094
Quote: Holy crap.
What WVL says!


what mace said
2013-01-21 20:11
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?
2013-01-21 22:38
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
        }
    }
}
2013-01-22 08:37
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 ;-)
2013-01-22 14:48
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?
2013-01-22 15:09
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
2013-01-22 15:10
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? ;)
2013-01-22 15:13
Cruzer

Registered: Dec 2001
Posts: 1048
Shouldn't it be mod(i,3)?
2013-01-22 16:07
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
}
}
}
2013-01-22 16:17
Burglar

Registered: Dec 2004
Posts: 1101
.var xsize = 2
.var ysize = 3

xsize/ysize is in sprites, not pixels.
2013-01-22 18:50
Magnar

Registered: Aug 2009
Posts: 61
Unfortunately same error even after changing the xsize and ysize values.
2013-01-22 18:53
Cruzer

Registered: Dec 2001
Posts: 1048
Give my previous comment a chance :)
2013-01-22 20:03
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)
}
}
2013-01-22 21:19
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)

2013-01-22 22:06
Cruzer

Registered: Dec 2001
Posts: 1048
Finally someone listens :D
2013-01-22 22:28
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!

2013-01-23 06:37
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
2013-01-23 08:16
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 :-)
2013-01-23 08:54
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!
2013-01-23 10:37
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.
2013-01-23 10:51
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 ;)
2013-01-23 10:51
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\
2013-01-23 12:29
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.
2013-01-23 12:39
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
2013-01-23 13:08
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.
2013-01-23 13:15
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 :)
2013-01-23 16:06
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.
2013-01-23 16:37
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.
2013-01-23 18:28
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.
2013-01-23 18:48
Cruzer

Registered: Dec 2001
Posts: 1048
@Burglar: Yes please, maybe I can finally be 1337 then :)
2013-01-23 19:30
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.
2013-01-23 20:00
Burglar

Registered: Dec 2004
Posts: 1101
I added the final version of the source to codebase64. Feel free to improve ;)

2013-01-24 07:57
Frantic

Registered: Mar 2003
Posts: 1648
Quoting Burglar
I 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 " "
	
2013-01-24 10:15
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.
2013-01-24 12:08
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.
2013-01-24 13:11
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.
2013-01-24 13:41
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".
2013-01-24 13:59
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.
2013-01-24 14:06
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

2013-01-24 14:25
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. :)
2013-01-24 14:27
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 :)
2013-01-24 14:29
chatGPZ

Registered: Dec 2001
Posts: 11386
"basically that's me :)"
you know what? EVERYONE knows that, since ninjas talk =D
2013-01-24 14:40
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 :)

2013-01-24 18:58
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.
2013-01-24 19:28
Burglar

Registered: Dec 2004
Posts: 1101
Quoting Groepaz
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

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 ;)
2013-01-24 20:58
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. ;)
2013-01-25 10:05
Bitbreaker

Registered: Oct 2002
Posts: 508
This adds well to what Frantic said :-P

http://www.youtube.com/watch?v=0oRX1t0Crek
2013-01-25 21:27
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
ΛΛdZ
zscs
csabanw
rexbeng
FunFun/Triangle
Guests online: 121
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.136 sec.