From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-23 02:48:46
Hello Ullrich,
UvB> Yes, that's true, but there are more than 10 programs and at least 5
UvB> libraries, burried somewhere in a deep directory structure. It is not easy to
UvB> pick the good parts from that:-)
[...]
UvB> Some of the code is really worth a look, so I would like to see access to it
UvB> as simple as possible. But it is of course your code, so this is only a
UvB> suggestion.
ok well, yes, that might be confusing.... i will have a look at it...
one major reason to keep my original directory structure was to make
sure that all the source actually builts without major hazzle (i
personally like makefiles in each directory as you might have seen
;=P). however,i think creating additional release archives that
contain one seperated program each should be easily doable, ppl would
need to compile them seperatly in that case though. (on the other
hand, i could then make them all reside in samples/whatever/) mmmh
well..... should i do sth like
/samples/c64/<prog>
for programs that are c64 specific (ie the plasma,
fire demo, radial demo)
/samples/<prog>
for programs that should be portable across cc65
targets
/contribs/<prog>
for anything else whose licence might be
incompatible with cc65 (NED possibly, i dont know
for sure about the bytebench and other stuff in the
/ports directory)
and what about the libraries...mmmh one archive for each lib and an
/include and /lib dir?
mmh and the testcode (the ported testsuite and some of the libtest
stuff i made myself) probably shouldnt go into /samples either? well
:=P
guess we should define something that works well for everyone ... also
some kind of naming sheme for the archives (i'd prefer timestamp over
versionnumbers for that matter ;))
what do you think?
(btw i noticed that snapshot is missing the silversurfer rs232
module i made.... gotta add that aswell :o) ... wasnt there some plan
about changing the api or sth?)
>> however... i guess the next thing i'll be doing related to cc65 would
>> be converting that gfx-related stuff into loadable modules that can be
>> used with (and merged into) the normal libs...
UvB> Having a second graphics module would be nice, because it would show problems
UvB> with the design that cannot be seen now as there's just one module written by
UvB> me (using S. Judds fine grlib as a base).
yeah probably... so is there a working example (that runs on the c64)
on how to use that stuff yet? shouldnt be a major problem to convert
the stuff i've done so far then.... maybe we can use some of the
"generic" code (like line and circle algo) to emulate missing
functions in the actual modules aswell...
--
Best regards,
groepaz mailto:groepaz_at_gmx.net
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-23 02:49:01 CET