Next version of xLIB - features?

Post by **tr1p1ea** » Wed 05 Jul, 2006 3:06 pm

The elements are all stored as 72-bit (plus exponent and stuff) BCD floating point, which is why they use decimals for collision detection and events.

Im not so sure that using decimals for collision detection is such a great idea. It seems like it would be slower than the old if tile < bleh method?

Jim e · Post by **Jim e** » Wed 05 Jul, 2006 5:53 pm

I refuse to believe that there isn't a way to force backwards compatibilty. Just making seperate routines would suffice no?

Using flags or offering up bits to give some other information can be really useful, but its all dependant on there being a tool to set said flags. Being that this is basic I beileve people would want on calc editors. So in other words you would need to make a map and sprite editor thats more advanced that whats currently availible to asm coders and have it on calc. Good Luck!

If you want to be really leet then you could create a special routine that creates a matrix format inside an appvar, that way basic coders can set flags and read numbers while not using 9 bytes. Say you could give them 2 byte signed number plus 8 flags. That should satisfy their needs while cuting the mem cost into a third of what it was. Or even better let them define the structure of the data. Hehe matrix[8][8].tile and matrix[8][8].enemy ha fun! Let them divi up the bits and you do all the work.

dysfunction · Post by **dysfunction** » Wed 05 Jul, 2006 10:37 pm

tr1p1ea wrote:The elements are all stored as 72-bit (plus exponent and stuff) BCD floating point, which is why they use decimals for collision detection and events.

Im not so sure that using decimals for collision detection is such a great idea. It seems like it would be slower than the old if tile < bleh method?

Collision detection is one thing; but decimals are also necessary for storing stats, health, magic points, shield, etc. In a game with only one or a few units in play, it would be fine to store those things in a separate list for each character, but in a strategy game like BSG it is by far more efficient to store stats for each unit with the unit's number in the map data.

crzyrbl · Post by **crzyrbl** » Thu 06 Jul, 2006 3:49 am

This is getting complicated pretty fast. maybe support the new map as real(15?

Post by **tr1p1ea** » Thu 06 Jul, 2006 5:14 am

This is all well and good, but i dont want this to become a multipage app, and i dont have much coding space left. Now do you see where im coming from?

crzyrbl · Post by **crzyrbl** » Thu 06 Jul, 2006 5:18 am

hmm, well, I guess it doesnt seem that important then. what does everyone else think?

kalan_vod · Post by **kalan_vod** » Thu 06 Jul, 2006 5:24 am

tr1p1ea wrote:This is all well and good, but i dont want this to become a multipage app, and i dont have much coding space left. Now do you see where im coming from?

A linking routine would surfice my needs

.

Post by **tr1p1ea** » Thu 06 Jul, 2006 6:54 am

I might see if i can implement maybe a CLAP routine in there ... but i feel that it will suffer the same fate as the DI Input routine.

Also with creating custom formats and such it makes it increasingly difficult for those begginers out there to get into it. I dont want to alienate them, as they are one of the reasons xLIB exists.

Jim e · Post by **Jim e** » Thu 06 Jul, 2006 5:33 pm

Oh you don't want to alienate them. Then ignore everything I have said or will say.

Was a call routine ever implemented?

threefingeredguy · Post by **threefingeredguy** » Thu 06 Jul, 2006 6:06 pm

YES! Call routine is a good idea. And linking.

Post by **tr1p1ea** » Fri 07 Jul, 2006 2:17 am

I dont think i will ignore everything you have to say haha

.

I will most likely be rewriting half of xLIB, so its possible that space will be freed up.

threefingeredguy · Post by **threefingeredguy** » Sat 08 Jul, 2006 2:35 pm

Possibly even MORE custom pic variables that are of variable size?

necro · Post by **necro** » Sun 09 Jul, 2006 4:42 am

custom vars file for storage purposes...like you name a set of vars ([A],A, B, C, D, L1, ListSave, Pic1, String5, String2, Y=1) and a asm prog for it, and the current vars are all loaded into that asm file. Just type a little command to snag all the mem back out and either keep the file as is, or delete it...if you would end up having a save for a pre-existing file, it would just prompt "over write programBLAHBLAH", yes/no

threefingeredguy · Post by **threefingeredguy** » Sun 09 Jul, 2006 7:42 pm

Local variables? Too much. But make variable sized bitmaps that we can scroll across, that would rock.

Post by **tr1p1ea** » Mon 10 Jul, 2006 3:19 pm

You can already scroll larger images by breaking them into full-screen sections. Then you can just use sprites: