From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-24 04:19:53
Yo again... :) UvB>> The current snapshot contains the 320*200*2 driver for the C64. The only [snip] ok, i've looked at it... gotta add some things to my own last mail :) g> mmmh just two chars to describe unique modes? thats very little if you g> ask me ;=P g> also, why put that restriction on a platform that dont need it when g> you translate from constants to real filenames anyway? (and also g> drivers would only work on one specific platform) that looks even less necessary to me now i've looked at it :) first of all i see no problem with having a tgi_modetable.s (or whatever it was :=)) for each target, and second..mmh, wouldnt it be better to have a function that scans the drive for available drivers and builts that table at runtime? ie, any non-trivial application might want to do that sorta thing anyway, and any trivial prog wont suffer from the additional overhead :) g> also wouldnt it be smarter to embed the type of resolution (or any g> other capabilities) into the module-file so the application really g> doesnt need to know which drivers are present? ok i see thats the case :) i also noticed you added sth that can deal with double-buffering (wasnt there last time i checked). cool... think i'll convert the 128x128x2 mode then first to check that out :) might take some time though, or is there an easy lazy way to drop in some c code into those modules? :) or should i maybe go for adding some emulation stuff in the gfx kernal instead? (i guess that can be done with c code easier?) g> (to me its an important g> point that additional drivers can be developed and used even with g> applications whose source is not available...and that also means they g> cannot be relinked against updated libs that know about new drivers) i can second that :) having to recompile a table of known drivers into an application statically makes no sence to me, not only because that would waste unnecessary memory (not much of a problem with the gfx stuff maybe, because we wont have tons of different drivers there... but the module thing could be extended to eg stuff godot does, loaders or viewers for different picture formats etc... and with the 100+ modules one can think of in that case such tables would easily grow larger than you wanted ;=)) imho there should be functions like - one that takes a gfx mode, in order to convert it into a target-specific filename. like the tgi_modetable, but a simple routine that encodes the gfx-mode constants into a reasonable unique and descriptive name. - one that takes a filename, in order to load a matching driver or return failure. - one that takes a gfx mode, in order to load a matching driver or return failure. like the current one does, but built of the previous two functions. - one that takes a filename, in order to return the drivers capabilities. this would be used by applications that support more than one driver and let the user select one interactivly. (programmer would have to scan the directory for *.tgi files and pass matching files to this function in order to built data for a menu or sth, and later load the driver by name) notice that in this sheme only drivers requestable by the application (ie standard gfx modes) need to match the naming-sheme...any "special" drivers might have different descriptive names and would still be useable in applications that allow to select them interactivly, and even be loadable by name by any other apps. (ie whatever you hack for testing the driver or sth :=)) maybe i'm just missing something, but how would i do the interactive-selection thing with the current interface? :) UvB>> You can take the source of the existing driver as an example. Some of the [snip] checked that aswell... actually quickly converted the 3dcube thingy to work with your driver, works nice...also clipping seems to work ok - and its even faster (well ofcoz it is ;=P) than what i did before...whopping 5fps now :) oh and.... maybe the makefile in the samples dir should also copy the tgi driver(s) to the disc :o) enough for tonite :=P zzzzZZZZZz :) -- 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-24 04:20:11 CET