The New xLIB - An APP

Jim e · Post by **Jim e** » Sun 01 May, 2005 10:24 pm

Wouldn't it be as simple as changing the name in the vat table. Unless you wanted to keep a copy.

necro · Post by **necro** » Sun 01 May, 2005 10:28 pm

It would be nice if you could just have an archived program that loads all of the needed pictures (0-9) without the need for 10 prgms to do it

Jim e · Post by **Jim e** » Sun 01 May, 2005 10:30 pm

I think tat brings us back to reading from a group idea, no.

DJ_O · Post by **DJ_O** » Sun 01 May, 2005 10:39 pm

I dont think it's a good idea to change everything and add too much features, trust me now we are near 5 level grayscale (one step further than desolate), adding that much stuff would kill it literally.

Jim e · Post by **Jim e** » Sun 01 May, 2005 10:44 pm

5 level?!? What 4 isn't good enough for you? It is completely at tr1ps discretion, I was just talking. But I really don't see why adding features, if it has the room, would kill it.

Toaster · Post by **Toaster** » Sun 01 May, 2005 10:51 pm

Umm this is a BASIC LIB 5 level grayscale would only make it go slower.

DJ_O · Post by **DJ_O** » Sun 01 May, 2005 11:00 pm

wouldnt it slow the program much?

well about 5 lv I was joking (maybe not), it's because I experimented 4 level grayscale in a title screen and it looked as good on my SE as your grayscale package

(yeah trust me) and I had to slow it down to sync with the LCD

but It will take a while before I experiment more 4-5 lv gray because sprite are uber hard to make and eat lot of space

basically I just dont want the lib to become slower than omnicalc :p

maybe tr1p should releaser one with just the contrast/zaddress/sprite/recallpic/tilemaps functions and another slower but high powered version

Jim e · Post by **Jim e** » Sun 01 May, 2005 11:12 pm

It wouldn't slow it down that much, he could just prioritize some things like sprites would be first and anything working with the archive would be last.

the_unknown_one · Post by **the_unknown_one** » Mon 02 May, 2005 7:15 am

Post by **DarkAuron** » Mon 02 May, 2005 10:41 am

Jim e wrote:It wouldn't slow it down that much, he could just prioritize some things like sprites would be first and anything working with the archive would be last.

Order of operations!

necro · Post by **necro** » Mon 02 May, 2005 11:22 am

the_unknown_one wrote:<offtopic> EBL WILL HAVE IT ALL! </offtopic>

make it an app!

Is there anyway to have something faster than the asm( command? As far as pictures go, I suppose that if it could just store multiple pics into a asm program (run with the asm( command and no extra parser hooks) and let you input option before running it like you could with the old xlib...it would be nice.

dysfunction · Post by **dysfunction** » Mon 02 May, 2005 12:50 pm

Perhaps if we could store multiple pic files in one compressed assembly program, then be able to call them from the app (imagine Zapi sprites with xLib speed!).

Post by **tr1p1ea** » Mon 02 May, 2005 1:21 pm

Well xLIB has a new sprite routine that can draw any size sprites anywhere (clipped as well) and from any pic.

I am not sure how fast it is, but kevin tells me that its good.

Also i wont be messing with storing stuff in programs or in the archive because this is a lib ... the less chance there is for a user to screw around the better. I have to allow for every scenario, there is already a fair amount of error checking.

The more simple it is, the better ... besides, i am pretty sure you can manage without having to pack pics into programs etc

.

DJ_O · Post by **DJ_O** » Mon 02 May, 2005 2:32 pm

there is alerady zpic that can recall pic from archive, zcopy to copy a program into another and Epic BASIC Lib that will contain a lot of features from xLIB and the zCopy feature. Of course I'll test both to compare speed and I will keep the fastest one (xLIB or EBL)

dragon282p · Post by **dragon282p** » Mon 02 May, 2005 5:21 pm

what about program writebacks?
Mirage and Ion has them or even better be able to use read/write/create Appvars in basic...