Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: tr1p1ea on June 18, 2013, 08:01:27 pm
-
Hi All,
As you may have seen, there has been a small amount of interest in bringing an ASM lib with some graphics features to the TI-84+CSE (84C for short).
I have been toying with a few small ideas that i may end up implementing in a preliminary version for BASIC programmers.
There are some pretty serious speed and memory limitations on the 84C which mean that fast paced BASIC+ASM lib games arent likely if the entire screen is utilised per frame. That being said, if there are a handful of sprites on screen at any time, this should be ok.
Just a note, there will be a radical difference between the way this lib and earlier versions of xLIB (for the 83+ etc) work.
Some of the proposed features:
32 internal but user accessible 16-bit variables (functions will take references to these variables instead of TIOS variables)
Graphics mode will be 160x120 (half res)
128x64, 256 colour (standard palette) custom PIC's (likely stored in appvars) ~8192 bytes+header. Enough to store 128, 8x8 tiles/sprites.
Ability to 'load' 2 custom PIC's into temp RAM for faster access
Ability to store 2 copies of the LCD into temp RAM (kind of like a temp storePIC)
8x8 fullscreen tilemapping (160x120 = 19x13 tiles)
256 colour (standard palette) sprites (not sure on max size yet)
Capability to 'chain' keypresses and update user variables if necessary (can test up to 16 keypresses with 1 command)
On calc PIC/tile/sprite editor
*Possibly* an on calc map editor
Line/shape drawing
Colour text routines
Archived program execution
And possibly more, but that for now.
One of the BIG traps that older versions of xLIB fell into was people requesting odd or specific features that would only be used *very* rarely, if at all. These considerably slowed the entire lib down for almost no benefit. This is something that i would really like to avoid with this incarnation.
Anyway ive been testing a few small things, but screenshots are difficult to make without a fully functioning emulator. But anyway here is a small tilemap test:
(http://i.imgur.com/op0X5cm.gif)
Simple sprite tests, with transparency as well:
(http://i.imgur.com/S1pD4aa.gif) (http://i.imgur.com/LaaXEsq.gif)
Scrolling is not ideal speed wise. Though there are options to speed things up (interlacing etc). The most probable method for games will be to scroll screen-by-screen if that makes sense.
Just wondering if anyone has any ideas/thoughts?
-
I'm really glad that xLIB is happening. I have some suggestions, though:
Tilemapping: I think it should not be limited to full screen, else we will not be able to draw HUD's and some people might want to make their games fit a smaller screen are in order to save speed. Even SNES games like Star Fox did it, after all. :P
What would be nice about tilemapping would be if data could be read from appvars, kinda, and preferably use a format similar to Axe, because matrices are ridiculously large and strings are a major PITA to use for collision detection.
Sprites: 8x8 I guess, but in the future it would be nice if any screen resolution is supported, for people who want quality over speed or vice-versa. I mean 320x240, 160x240 and 160x120. You could maybe include 16x16 support eventually, for people who want their code to be smaller and faster.
Resolution: I think you should allow people to enable interlacing or not (via an extra argument?). People who absolutely want 160x240 resolution can then just use two set of tiles then display the tilemap twice, with one copy offset by 1 pixel vertically. (although such graphics might be hard to draw :P).
Real(10 command to copy archived programs to RAM, which would be nice since the calc has smaller RAM.
Anyway this looks promising. By the way, have you tried TilEm and SourceCoder emulators? They can run ASM programs, although they can't setup the 160x240 res mode IIRC. Just capture with Camstudio then edit the screenshot in VirtualDub to crop the second half of the screen, then stretch it up to 320px and export as GIF. Else I could maybe do the screenshot for you (although that could take a while)
Good luck!
-
Tilemapping most likely wont be limited to fullscreen only to allow space for HUD's etc.
The data will not be stored in matrices as they are too slow! Id say they will be stored in appvars as well. Im not sure what the largest size map should be ... 64x64 (4096 bytes)?
Sprites will have the ability to be any size up to 64x64 i think. But the way they are stored in the PIC files will be in 8x8 chunks.
By interlacing are you referring to only drawing every 2nd line (and having black in between)? Im not sure if this would be one of those features that not many people would use since lots of detail is lost on screen. But it would be good for speed.
Copying programs from archive to RAM will be included.
I havent come across an 84C version of TilEm yet, but i have used jsTIfied. The issue with screenies is that xLIB uses the 'non-active' portion of GRAM as a buffer so it needs 160x240 mode to be emulated in order to construct proper screenshots (cropping and resizing wont give proper screenshots).
-
This looks great Tr1p. As the original xLIB was a huge asset to programmers, I'm sure this will be the same.
-
Tilemapping most likely wont be limited to fullscreen only to allow space for HUD's etc.
The data will not be stored in matrices as they are too slow! Id say they will be stored in appvars as well. Im not sure what the largest size map should be ... 64x64 (4096 bytes)?
Sprites will have the ability to be any size up to 64x64 i think. But the way they are stored in the PIC files will be in 8x8 chunks.
By interlacing are you referring to only drawing every 2nd line (and having black in between)? Im not sure if this would be one of those features that not many people would use since lots of detail is lost on screen. But it would be good for speed.
Copying programs from archive to RAM will be included.
I havent come across an 84C version of TilEm yet, but i have used jsTIfied. The issue with screenies is that xLIB uses the 'non-active' portion of GRAM as a buffer so it needs 160x240 mode to be emulated in order to construct proper screenshots (cropping and resizing wont give proper screenshots).
Ah ok, I didn't realize matrices were slow. They seemed faster than strings to me (at least for collision detection). But appvars would be better as it would be smaller.
Sprites that are 64x64 seems fine to me. Else I guess 32x32 or 16x32 would be fine as well. Most large sprites will most likely be enemy data for RPGs and bosses for other games.
For the emulator, as I said, you could just use a video capture program then edit the screenshot resolution afterward, cropping the non-active portion of the GRAM out. This is what I did with my older screenshots to fake the 160x240 mode:
(http://illusiat.reubenquest.net/xlib.mtv-music-generator.com_imagesThatWereOn57o9WhereJujuShouldPointTheXlibMTVMGSubdomainToBeforeWeLoseTheGame/zeldalastyle.gif)
As for interlacing, see image below for what I mean (basically you don't even need to implement 160x240 mode, as long as you implement scanlines):
-
Cool, though i think ill add the scanline option after the majority of the graphics routines have been written - to ensure consistency.
Also i forgot to mention that sprites will have an optional transparent colour index as well!
-
I like the transparent color idea. By the way, how will palettes be stored? Will each sprite have their own palette or will it be one palette at once for the sprite sheet?
-
There is a standard 256 colour 'xLIB Palette' that graphics need to use. This is not required to be included with the sprites/PIC's themselves.
-
Ah ok I see now. I guess in that case too it shouldn't take too much memory. I worried that each sprite had its own palette, so that would have been quite large >.<
Will line/rectangle routines be forced to 120 px height btw or will they be able to use the full res?
-
Good luck with this! :D
-
On a side note tr1p1ea, since xLIB is starting to get old, a lot of younger TI-Z80 programmers are probably unaware of what the original version was, here. So as a suggestion, I would change the topic title to xLIB 84C - fast ASM lib for BASIC programmers or something like that, to attract more people. :P
-
That looks quite nice feature wise ! I hope you'll get a good speed once it's finished. :D/me wants a CSE
-
Well, it seems that 3rd party app development is off to a better start than TI's app development! We already have two released apps (BrandonW's Linky beta and my MicrOS), and now a third in development. I suspect that performance issues will push even more BASIC coders to adopt assembly augmentation.
Also, I'd like to suggest possibly using the ExecLib command as your hook for BASIC functions, for it might be faster. Based on what I'm seeing in the USB8X source, you specify using ExecLib by putting the byte sequence 96 E2 00 01 at 40A0 in your app. Then, put a short pointer to a header continuation, which then contains the bytes 01 00 02 00 followed by a pointer to your ExecLib handler. These two extra headers can be sequential. Why TI didn't just make this part of a new app header field I can't image, but maybe BrandonW can.
-
Ive thought about OpenLib/ExecLib, but i thought there were issues with using it? Ill check it out :).
(Also thanks for the APP info :)).
-
On a side note tr1p1ea, since xLIB is starting to get old, a lot of younger TI-Z80 programmers are probably unaware of what the original version was, here. So as a suggestion, I would change the topic title to xLIB 84C - fast ASM lib for BASIC programmers or something like that, to attract more people. :P
Wasn't it that you have to put stuff in ans and then call Asm(prmXLIB ?
And nice thingy, the xlib for the cse!
i /really/ should get one...........
-
Old version of xLIB were like that, but the long running version installs a parser hook which intercepts any real( commands.
-
A token hook like omnicalc used to use would be kinda cool >.<
-
Did some sprite tests on a tilemapped background:
(http://i.imgur.com/S1pD4aa.gif) (http://i.imgur.com/LaaXEsq.gif)
Left screenie is with no transparency, right is with the transparent colour specified.
The tilemap is drawn as a background and the sprites are drawn over it. The tile that the sprite is over is redrawn every offscreen frame to effectively 'clear' the sprite. The map is not drawn every frame, rather it serves as a background.
-
This looks amazing tr1p!
-
What part of the program handles the re-drawing of the tiles ? The Basic part I guess ?
Keep up the good work :)
-
tr1p1ea, this is awesome! Also, the ExecLib and OpenLib ideas are great. The problem before was that it limited programs to be used only by the 84+ calcs since those weren't available to 83+ users. But now, since programs like this cannot be compatible on older models, it makes sense to use them!
-
If I remember correctly, the main problem with OpenLib (which still remains on the 84+CSE) is that the App must have a name exactly 8 characters long, all capital letters or numbers.
-
/me REALLY wants one now.
-
If I remember correctly, the main problem with OpenLib (which still remains on the 84+CSE) is that the App must have a name exactly 8 characters long, all capital letters or numbers.
Aren't spaces allowed ?
And that's definitely cool tr1p ! Keep up the good work !
-
wow, that does look awesome. I love it how everypony uses zelda links awakening for tilemap tests >.>
Is it just me or is the transparent version a bit quicker O.O
-
Looks very great tr1p! By the way, do you think people will be able to have both DCS and xLIB CSE installed at once? Back in the days, xLIB games often received backlash from the TI community because of how it required uninstalling Symbolic, Omnicalc and such school apps or vice-versa.
Maybe try to use a different token than anything DCS7 used?
What is chaining keypresses, by the way? Is it just multiple keypresses or is it something else?
Also, since xLIB constantly swaps between both sides of the GRAM, do you think this will pose problem for static HUDs and drawing text?wow, that does look awesome. I love it how everypony uses zelda links awakening for tilemap tests >.>
Is it just me or is the transparent version a bit quicker O.O
It is possible, since drawing on that LCD is slow. Although detecting transparency might take a bit more processing power, it is possible that just displaying fewer pixels negates the speed drop.
-
Runer112, calc84 and i were talking about hook standards and such yesterday. A standard hook manager needs to be created; this likely wont happen for a while. There are the alternatives of OpenLib( and ExecLib( however one of the issues with this the handling of arguments, which will require excessive abuse of Ans.
With a parser hook you can effectively do things like: real(0,1,real(1,0),5 ... etc. I can use a different token if need be, but regardless of the token the hooks still need to be chained (not that there are any actual hook programs for the 84C yet).
Chaining keypresses means you can submit a list of keys to test at once, and add/subtract a value from a variable if true.
real(2,number_of_tests,key1,variable1,value1,key2,variable2,value2,key3,variable3,value3 ...
Instead of having multiple key commands. This actually speeds up things dramatically.
Also the screenie with the transparency has a better sprite routine than the first screenie which is why it is a bit faster. The gif might not be completely accurate however.
-
Should a topic on hook standards be made? It will require going back and forth between sites to make sure everybody is on the same page. I do think that a setup like this is very useful:
AppStart:
jp Main
.db 84h,43h
jp HookInstall
jp ParserHook
jp KeyHook
jp MenuHook
...
Even if your app didn't use certain hooks, placing dummy jumps would be a good idea. This way it is very easy for other programs to run your hooks or install them. As well, making sure (as best as possible) that your hook doesn't modify inputs if it doesn't use it is an excellent idea. Then we could make some kind of appvar (or preferably a symbol variable, since it is faster to find) that simply contains a list of pages that "registered" apps can be accessed on. So if a new app wants to add itself to the list, it would need to locate the variable, augment it by 1 byte, and add its page to the list. Then any hooks would run through the app list calling their hook code from the jump table. The biggest issue would be that we would need to use the routine on another page x.x
-
Yeah I agree that a topic on hook standards might have to be made. As for apps that might use parser hook features, I think the only one that is likely to use them is Doors CS8.
As for chained keypresses, will a tutorial be made on how to use them? It seems far different from standard real(8 or getkey commands seen before, so it might be harder to understand for newer programmers.
-
Its virtually just an extension of the getkey command that can conditionally add/subtract a value to any user variable if the appropriate key is pressed. It saves having to do the old way of:
get key value
if key=?? then update variable1
if key=?? then update variable2
etc ...
Also here is a screenie that demonstrates how xLIB uses GRAM to buffer graphics:
(http://i04.img-up.net/13717402382c74.gif)
-
This looks kinda nice actually, but when we draw text in the first half, is it copied over the second half automatically or do we need to draw it twice using the Text commands?
-
Flipping the LCD is pretty much like doing a fastcopy in old xLIB. So you will need to draw text twice if there is stuff moving in the background.
To further explain the getkey function:
if you just want to get the key in Ans then you can do:
real(2,0
And the key will be in Ans, the same was as its always worked.
The demo however takes advantage of the extra functionality of getkey. Namely that it can update USERVARIABLES depending on what keys are pressed:
real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8
Will add or 8 or -8 to user variables 0 or 1 depending on if up/down/left/right are pressed.
Here is a breakdown:
real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8
real( = xLIB token (for now)
2 = getkey function number
4 = number of keys to test
4 = keycode for UP
1 = USERVARIABLE 1, being used to hold playerY
-8 = value to add to USERVARIABLE 1 (playerY)
1 = keycode for DOWN
1 = userVARIABLE 1, being used to hold playerY
8 = value to add to USERVARIABLE 1 (playerY)
2 = keycode for LEFT
0 = USERVARIABLE 0, being used to hold playerX
-8 = value to add to USERVARIABLE 1 (playerX)
3 = keycode for RIGHT
0 = userVARIABLE 0, being used to hold playerX
8 = value to add to USERVARIABLE 1 (playerX)
This way you can do 4 key tests and update the variable appropriately in 1 real( statement. The reason for this is key handling was possibly the biggest reason for slowdown in BASIC games.
Currently it only supports addition, but that can be expanded. That said you would probably have your movement work like this and if you have menu keys you can process them seperately. That said the way it has always worked hasnt been taken away so the standard way to handle keys is still there.
I should mention that the lib will require very different coding techniques over previous xLIBs or other ASM libs. This is unavoidable due to the speed limitations of the platform. Here is the code for the sprite demo:
:real(1,1,0,0
:real(1,1,1,0
:real(1,1,2,0
:real(1,1,3,0
:real(1,1,4,127
:real(1,1,5,0
:real(1,1,6,0
:real(1,1,7,64
:real(0,1,0
:real(3,0,5,6,7,0,0,1
:real(3,0,5,6,7,0,0,0
:real(1,1,8,real(3,1,0,1,7
:Repeat real(2,0)=15
:real(4,0,1,8,8,0,4,239,1
:real(4,2,3,8,8,0,8,1,0
:real(1,1,8,real(3,1,0,1,7
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
:real(2,4,4,1,‾8,1,1,8,2,0,‾8,3,0,8
:End
:real(0,1,1
-
I see. I think that might be a problem for games with HUDs, although I guess one could just make sure that nothing else needs to be drawn when displaying text or if he's making an ARPG he could just make sure that not too many text have to be updated on the screen when killing enemies.
By the way, will we be able to set the text background color via xLIB? In BASIC it's impossible but I think if it's changed in ASM, then it doesn't get changed again until you use the BASIC command TextColor()
As for the getkey commands, could you maybe explain it in a visual manner, perhaps with code example inside a loop and a screenshot (even if glitched up for reasons mentionned earlier)? Because I will never understand it if it's explained the 83pa28d way instead of Hot_Dog-Z80-Guide way. >.< Else I'll most likely end up just sticking with the TI-BASIC command.
EDIT After reading your EDIT, I understand more now. What kinda confused me was the variables part, since I saw numbers instead of A-Z/Theta, but I also got confused because I had no clue what was the breakdown. Thanks :)
As for the different coding techniques, could you cite some examples?
-
Oh, that key thing can come in handy!
And that is an interesting way on how to make two buffers.
-
Off-topic: Why was this topic locked? I assume it was a mistake by tr1p1ea (since members can lock their own topics) or a staff? ???
(Thanks juju for unlocking it btw)
-
Opps i was on my phone, must have hit lock topic when trying to change pages :S.
Also the reason people use Link's Awakening is because they are 16x16 tiles im pretty sure where most other Zelda games have a higher resolution (Aside from NES etc).
-
Hmm, so what is actually going on in that screen? Is it that half of it is displayed to the user while the other half is some kind of backup?
-
I think it's like the graph buffer on monochrome calcs but it's in GRAM to save actual RAM and also a lot of speed. :D
-
Thats correct, since in 160x240 mode only half of GRAM is needed (and you set which portion of GRAM is visible) i use the non-active half as a buffer, then switch it in when drawing is done.
-
It's a good idea, because drawing in another RAM area then copying it over the GRAM when done would have really been slow on this calc. On older models it was fast only because the screen contained much less data.
As for LA sprites lol I remember when DarkAuron ranted on Maxcoderz about how overused they are, but I think it's fine because no Zelda using them ever got finished anyway.
-
You know that is a fair point! I think the only released Zelda ive seen that used them is the demo that came with Duck's Grayscale Programming Package? There are likely other demos though.
-
Well I really meant finished Zelda games. So far the only two that ever got finished (ironically both within one month span) are Dark Link Quest and Hero of Hyrule. The first is ASCII and the 2nd uses custom graphics that looks very close to Link's Awakening, but scaled down, and it isn't as much of a Zelda game as DLQ. But yeah among unfinished ones, I never saw any using anything else than ASCII graphics or LA sprites/derivatives. I guess that maybe people just found the NES graphics too bland but found the SNES/GBA Zelda ones too complex to be converted to 4 shades of gray.
I personally would probably re-use LA graphics, but I'm not planning to do a Zelda game in xLIB (probably a 84C exclusive RPG or something). I am already making a Zelda in BASIC which is intended to be as small as possible and graphical while staying as TI-BASIC as possible, and I'll probably leave other Zelda projects to ASM/Axe coders, while I try to work on new original stuff. :P
-
I'd really like to make Golvellius for the TI-84+CSE (which was Sega's SMS version of Zelda) - hopefully I'll get around to it!
-
I didn't hear much about that game but I think you were working on a calc remake back in the days, right? I need to check that stuff out at one point. :)
-
I didn't hear much about that game but I think you were working on a calc remake back in the days, right? I need to check that stuff out at one point. :)
Yeah, I tried making it for the TI-86 around 11-12 years ago, but A) I bit off more than I could chew, I wasn't ready for such a large project, and B) the ~10K code limit on the 86 was a big issue. If I do attempt it on the 84+CSE, it would be a multi-page app :)
-
Ah I see, and yeah I saw on the page that it was kinda too much, according to the description. I should try your two RPG demos at one point, though. They look quite good.
-
I haven't had the chance to say congratz, it looks awesome ;)
I wonder if other well-known libs are going to be updated too for the 84C....
Oh well, as long as the best ones do :P
-
Question, for xLIB GRAM updates, will we be able to specify when we want the LCD view to be updated without necessarily having to draw anything? It would be nice if we could switch between both GRAM areas as we see fit, for example if we're doing a lightning animation and the sky has to flash between two colors very fast.
Otherwise, will there be a screen shift command like LCDTOOLs? It lets you move the screen around in both 160x240 and 320x240 mode. This might be anothere option, while also allowing some kinds of scrolling animations or earthquake effects.
-
Yes you can switch gram at any time, scrolling is only a few lines of code so no problem
-
Good to hear :D
Two things I am thinking about are flashing animations such as lightning spells that requires heavy speed to update the entire screen, along with cinematic sequences that requires fast animation such as running or moving background, like in Zelda Dark Link Quest. Of course those would not be full screen in order to save space, though. (kinda like NES/SNES/Turbographx movie-like sequences)
-
Did some sprite tests on a tilemapped background:
(http://i.imgur.com/S1pD4aa.gif) (http://i.imgur.com/LaaXEsq.gif)
Left screenie is with no transparency, right is with the transparent colour specified.
The tilemap is drawn as a background and the sprites are drawn over it. The tile that the sprite is over is redrawn every offscreen frame to effectively 'clear' the sprite. The map is not drawn every frame, rather it serves as a background.
This is looking really nice Tr1p. Speed looks quite good here. :)
-
By the way, will xLIB 84C support the the ability to display colored fonts over the home screen? Currently, in BASIC, only monochrome stuff can be done on the home screen.
Will we be also able to change the color of the text background on the graph screen to something else than white and gray? (it switches to gray when using white, yellow or light gray text)
-
Coloured fonts are part of the plan :).
-
Cool to hear. One thing that would be nice is if there was a command to replace Text(, but used transparent text like on the HP-39gII and also used some sort of custom 5x7 font (maybe the ones by TI lol) instead of the default ones, since with the default ones you can fit like 13 characters per line with large fonts :P (in small res mode).
-
I think transparent backgrounds on text would definetly be nice. :)
-
Also I think that text should use monospace fonts, unlike the small TI fonts. It kinda sucks to have to display each char one by one on older models in order to ensure that each chars are at equal spaces and it's slower. With monospace fonts we can just display like 25 chars at once in a line then use the speed at our advantage to add shadow effects and stuff by drawing white text over black one (like I did in my HP 39gII tunnel)
-
So you mean that fonts are 'fixed-width' in that every character occupies the same space? As opposed to variable width fonts where 'W' and 'I' take up a different amount of space?
There are advantages to both kinds i guess, in actuality it should be easy enough to specify which method you want to use.
-
Indeed that's what I mean. Granted, without that we don't end up with huge gaps between short chars, but it's really annoying for game development sometimes, particularly for NPC convos in RPGs that use a text/dialog engine.
-
(http://img.omnimaga.org//test.gif)
Here is an incredibly crappy quality screenshot showing 16x16 sprite (with transparency) moving around. It appears to run a little slower than on calc (due to capture issues).
The 16x16 sprite is made up of 4 * 8x8 tiles. You can specify which tiles in a PIC make up the sprite, and they dont have to be in order in the PIC either.
For example you could say that tiles 1,2,3,4 make up your sprite, or if you say want to have the same body but a different head on the sprite you can say that 55,56,3,4 make up the sprite etc (if that makes sense).
The screenshot is actually drawing 2 16x16 sprites since the 4 tiles that are 'behind' the main sprite are calculated and drawn every off-screen-frame in order to clear the sprite. This saves having to clear and redraw the entire screen ... which would be very slow!
-
By the way do you use a tripod for those screen captures? They're much better quality than many Youtube vids.
Also I like the idea of using 4 8x8 sprites but via a list to show all of them at once. Sometimes, we want to use large sprites, but don't need to update every square, thus, we waste space and speed. Only displaying the necessary parts this way will be better :)
-
Normally i would stack some stuff up and try to keep everything stationary (im just recording from a phone).
However im currently out of town on business for 2 weeks so i didnt have access to anything in my hotel room :/.
But the quiet time is a good opportunity to get some coding done :).
EDIT - Here is the code for the demo program:
:"set user vars
:real(1,1,0,0
:real(1,1,1,0
:real(1,1,2,0
:real(1,1,3,0
:real(1,1,5,0
:real(1,1,6,0
:real(1,1,7,64
:"set 160x240 mode
:real(0,1,0
:"draw tilemap (to both sides of LCD)
:real(3,0,5,6,7,0,0,1
:real(3,0,5,6,7,0,0,0
:"loop until clear is pressed
:Repeat real(2,0)=15
:"draw character sprite, updateLCD
:real(4,0,1,2,2,0,249,1,0,124,125,126,127
:"draw tiles behind old character sprite to inactiveLCD section
:real(4,2,3,2,2,0,1,0,real(3,1,2,3,7,0,0),real(3,1,2,3,7,0,8),real(3,1,2,3,7,8,0),real(3,1,2,3,7,8,8
:"copy old character position to temp position
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
:"test for keypresses, update x/y depending on arrows
:real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8
:End
:"restore LCD to normal mode
:real(0,1,1
-
Interesting. By the way you should put what each Real command do in the first post, for example real(1, real(2, etc, so when this comes out (beta, final, etc) and people post code, it would be easier for people to learn the language. :)
By the way, I notice the real(0,1,0 command there. When updating the screen content, I assume that it will automatically set 160 by default then alternate between both GRAM areas, right? Also is there an argument in that command that lets you change the screen position, for example for earthquake effects?
Also what's with the real(4,2,3,2,2,0,1,0,real(3,1,2,3,7,0,0),real(3,1,2,3,7,0,8),real(3,1,2,3,7,8,0),real(3,1,2,3,7,8,8 thing? O.O
-
You do need to set the screen to 160x240 mode before drawing, otherwise you will only be able to draw to half a screen. I could have it do it anytime you try to draw something however.
I will add the ability to offset the LCD if needed, its only a few lines of code.
The command is used to draw 4 8x8 sprites which are the tiles that the sprite is currently over (to erase the sprite).
real(4 is draw sprite so:
real(4,x,y,w,h,pic,transcolour,updateLCD,tile0,tile1,tile2,tile3 ...
for tile0 etc there is: real(3,1,2,3,7,0,0) which is the 'getTile' command (real(3,0.. is drawMap, real(3,1.. is getTile) so:
real(3,1,x,y,mapwidth,xoff,yoff) where xoff/yoff is an offset you can provide that will add to x/y so that you can get tiles for larger sprites. The result is stored to Ans (and is just used inline in the example).
Sprites are drawn in 8x8 chunks, but also in columns first, then rows.
-
Yeah about 320x240 I meant for people who plan to use some weird tricks in their tilemaps or something :P. I personally probably will only use 160x120, though (160x240).
Also thanks for the commands doc. :) As for GetTile, I like the idea, since this will make collision detection much easier. :)
Also, regarding map data, will it be possible to use boolean logic for a tile ID or will we have to create a second (modified) copy of the tilemap to load or even hard-code map modifiers? For example, in some of my games, after you activated a switch in a dungeon, a path in the wall would open. However, when leaving the room that path had to remain open, meaning that when you came back in, the path had to be immediately displayed as open.
-
Well the map will site in temp RAM and you can modify the tiles in it however you like. You just cant save it back to the original data.
-
As usual, this looks incredible! Great work Tr1p!
-
That looks awesome tr1p!
You make the slowness of the screen look non-existing O.O
And you make like every game seemingly possible.....
-
Well the map will site in temp RAM and you can modify the tiles in it however you like. You just cant save it back to the original data.
Yeah but as I say, the issue is that if might be annoying to have to modify the data by default everytime you reload the map. If, for example, the game has a total of 500 treasure chests, then this means that my map loading code will contain 500 If instructions checking each map that contains treasure chests >.<
-
How would you have done this normally on the 83+? I guess people never had their maps in archive?
Also i thought of a great idea! I can use ExecLib( so that BASIC programs can enable/disable xLIB from within their programs! I wonder what the TIOS throws should xLIB not even be on the calc?
-
Here is a map from Reuben Quest: Ev Awakening, for example, using matrices in xLIB 0.1a (non-APP) format:
:If N=5821
:[[16,16,16,16,16,16,29,11,39,40,27,16][16,16,16,29,27,29,41,11-(L1(1)=4),11,11,39,15][28,28,29,41,39,41,11,11,11,10+(L1(1)=4),11,15][40,40,41,11,11,11,11,11,11,11,11,15][11,11,11,11,11,11,11,11,11,11,3,16][4,4,5,11,11,11,11,11,3,4,4,16][16,16,16,5,11,11,11,11,27,28,54,55][16,16,16,16,5,11,11,11,39,40,66,67]]
From what I recall, this is the gate near your house that you need to open by beating the first boss. After the first boss is defeated, the gate is replaced with normal tiles you can pass on. For size and speed reason, NPCs and event tiles in that game are part of the maps.
-
Just a small colour drawLine test. Note that this is in 160x120 res ... but i have limited the random line coords to the middle ofthe screen because there is no clipping.
Also its a jsTIfied screenie so its a lot smoother in reality:
(http://img.ourl.ca//drawline.gif)
-
that is quick.....and it looks awesome O.O
and now to adding clipping :P
-
Just a small colour drawLine test. Note that this is in 160x120 res ... but i have limited the random line coords to the middle ofthe screen because there is no clipping.
Also its a jsTIfied screenie so its a lot smoother in reality:
(http://img.ourl.ca//drawline.gif)
O.O
Is it me or this xLIB is much faster than the other one? I know this lacks line clipping support, meaning it's much faster already, but still... awesome.
By the way, will there be a command to change the contrast (and store contrast value to Ans to reset contrast back to its original state) and even turn the screen ON/OFF? I saw that Buttonz turns the screen OFF during transitions and I thought this would be nice to have this in xLIB.
-
Well i should say that this is a raw line test, so the xLIB commands will be a bit slower. But still it gives a good idea of the colours that can be used.
That being said this routine is 8-bits only, so i do need to extend it to allow for the full range of coords.
-
Could you post how the color palette looks like btw? (As well as the values)?
-
Here is a colour polygon test, this is NOT optimised but the speed seems ok (a lot smoother on calc):
(http://img.ourl.ca//1374614485.gif)
-
wow, just wow
-
This is the palette of xLIB C
(http://img.ourl.ca//xlib84c.png)
Tr1p1ea posted it in the mockups topic, but here is where it belongs.
-
It supports polygons?? O.O
Btw how is the progress on the main routines such as tilemapping, sprites, copying archived programs to RAM, screen shifting? Do you still plan scanlines support?
-
Tilemapping is basically complete, just adding some further functionality to it (getTile commands etc). Also need to add the ability to have different sizes aside from 20x15.
Sprites are complete, just want to add further functionality like a checkCollision between 2 sprites
Copying archived programs to RAM is done.
Screen shifting can be done (horizontally), but the results wont be as expected since xLIB uses the unseen portion of GRAM as a buffer (and thus you will shift into it).
Im not sure about scanline support, is there a big demand for this feature? It requires a rewrite of all graphics routines and a completely different method of storing graphics (and a different screen mode too)
-
Scanline support would be more suitable for sprites and tilemap display. It is more for people who would prefer to use two sprite sets with one of them offset by 1 pixel, so that they can mimic 160x240 mode, or for people who are in extreme need of speed and don't mind reducing graphics quality by only displaying every 2 line.
Do you think there could be a demo or something somewhere before or into the beginning of the next school year, in case new games begin being worked on and make students buy the calc more?
-
Would using 2 sprite sets be overly complicated, especially for beginners? I can look into it, but like i said, it requires a complete rewriting of the entire application (which would destroy any speed benefits that already exists).
Also ... what time does the school year start in the northern hemisphere? :).
-
The main issue would probably be separating the sprites using images editors. It's not a big hurry, though. Maybe when xLIB is completed, that could be an extra feature addition? (Although in such case, it might be best to just use 8x16 sprites that are not scaled up lol). I would say leave things as they are for now. At first, people will probably try starting smaller anyway to get used to the new lib.
As for school start, it depends of the school, but normally it starts around August 25th-September 1st. Sometimes in mid August we get a small rush of people asking calc help, but the biggest rush is usually in October after the ACT/SAT tests. It should be September, but everyone seems too busy then. There are 2-4 weeks of vacation during Christmas holidays then people end school in May-June.
Oh and also by demo it can be closed beta or anything lol.
-
Once i add a few little things i can give you a demo to try out :).
-
Looks awesome tr1p1ea. That ploygon test looks especially amazing, I can see it used in first person games. Thanks for the tip on the color convention. I'm probably going to use it in IViewer as an 'easy' image converter option. It would match up the colors as close as possible, cutting the size instantly in half! Now I know who to go to for graphics :)
-
Thanks :). Most images i have tried convert quite well for 256 colours which is a big bonus!
That sounds like a cool option for IViewer :).
-
The lower palette of xLIB compared to the 16 bit one supported by the calc probably won't make much of a difference in quality when viewing the images on the calc, assuming they are dithered, because of how tiny the pixels are. So I guess it would be fine for IViewer.
-
This isnt a xLIB test, but i did a small solid 3D cube test:
(http://img.ourl.ca//1374706926.gif)
The capture is pretty rough and there are some issues with high-speed switching between GRAM regions that need to be ironed out. It also runs faster than the screenshot demonstrates (and smoother).
Its only some rough 3D routines so i havent added any culling or anything ... its just a test :).
-
Looks very nice. How does rotating works btw? Do you just erase the edges or do you erase the entire cube then redraw it? Also how fast does it run if each face got a different color?
Btw when xLIBCSE is officially released, I think multiple example programs such as the ones demonstrated so far should be included in a folder, much like with Axe Parser.
-
Wow, this is looking pretty awesome! Great job!
-
Wow, those polygons look great!
-
By the way tr1p1ea, a good trick to make smoother screenshots would be to slow down your programs to about 30 times their original speed, take a capture then speed it back up to the original speed in VirtualDub. Just make sure that the screenshot speed remains as accurate as the calc, though. This is what I do with Nspire screenshots when I want quality, because I can't get more than 7 FPS on this computer for such animated screen captures, but luckily the Nspire emulator supports slowdowns.
-
Well its a small 3D test, but like i said there is no culling or sorting so different coloured faces wouldnt work correctly. That said different colours are the same speed.
It draws a frame, then swaps GRAM buffers and erases the old frame (it draws over the old polygons in white as opposed to clearing the entire screen).
Im sure there will be loads of example programs since the way this version of xLIB works is fairly different.
Good tip with the screenshot btw!
-
Ah I see now. Thanks for the info. :)
As for the screenshots just make sure to link to them, though, if you make any like that, else they will be like 8 MB large :P
-
Well i can convert it to a better frame-rate but decimate the frames to reduce the file size too. Its difficult to make screenshots when you are switching between the left/right of the screen.
-
Yeah true. By the way how do you make them now? Do you manually edit them frame by frame? Because that must be long! O.O
-
For small screenies i just remove every second frame, but thats what makes it jumpy. Still it does make me happy that maybe i might have a chance of porting my 3D engine over to the 84C.
I will hopefully have time to knock over some of the remaining features so that users can properly test sprites/tilemaps.
-
Oh I see now. I guess that works then. And yeah a port of the 3D engine would be nice. Please don't go too overboard on 3D features, though, because many inexperienced programmers and new community members will go nuts when seeing screenshots of more advanced projects then all start trying making 3D games, even though they have zero experience in 3D and that BASIC is slow. Even in Axe we have yet to see proper 3D games (non-raycasting/mode 7 I mean)
-
I dont think that ill include any 3D routines in xLIB since it can get quite complicated. I will have the shape drawing available however. It will be recommended that people stick to sprites and tilemaps.
That reminds me, i need to implement a text routine!
-
I guess you could just write a BASIC+xLIB program that showcases the polygons and your 3D routine, to show its potential. Can we chain polygons like with sprites?
As for text, you could always just re-use the sprite routine but via a different syntax (assuming, for example, that text is made of 8x8 sprites containing 7x7 chars), eg:
real(666,X,Y,Stringoftext,<NumOfCharPerRow,TxtColor,BgColor,DoYouWantToSwitchGRAM>
1) Anything after Stringoftext would be optional and if BgColor isn't specified it would be transparent by default.
2) X and Y could be any number from 0 to 159 and 0 to 119 respectively, not just multiples of 8. This would allow people to do special effects with text such as scrolling, shadows or bold text.
3) Idk if chars per row would be hard to implement, but it could be handy for people with RPG boxes. Anything you display outside the current GRAM area would be clipped.
4) For the font, if you go with 7x7 this allows a max of 20x15 chars at once in the screen.
Then comes the problem of displaying variable content via such text routine. Some people might want to show HP/MP, so what you could do is:
1) If user displays a real var instead of text or str var, just display that number instead as you would do with the BASIC Text command
2) If user displays ONE element from a list, do the same as in BASIC
3) If user displays ONE element from a matrix, do the same as in BASIC
3) If user tries to display anything else (such as an entire matrix or even a pic), trigger the ERR:DATA TYPE msg or do nothing.
Else, if it's too complicated, you could always only show content from the Ans var, nothing else.
-
It might be more useful to display text from Ans given the way the backend of the parser works. Plus this would allow you to build strings from various sources if need-be.
Im thinking for a start that the text will always have a transparent background (and you can draw a filled rectangle behind it if needed). You will be able to write text at any position on screen.
-
Yeah I guess that could work too. Also good idea about the background lol. Actually I guess this makes sense since most people will display text over a window or the map anyway, so on a window he already has a background setup anyway.
-
Thanks for all the great ideas DJ!
-
Hopefully this works (posting from my phone). Anyways, my idea was to be able to draw text vertically and to also be able to treat a string like a 2D array and given a height and width argument, extract a row or column (with clipping). This would be useful for text based tilemaps, but this is just an idea. This would probably be a better idea applied to drawing a single row or column of a tilemap. I hope this makes sense!
-
Drawing text vertically would make it hard to display actual sentences, though. O.O
Imagine if your text is:
"HELLO WORLD!
HOW ARE YOU?"
Then your string would need to look like this XD:
Prgm:NAME
:"HHEOLWL OA RWEO RYLODU!?"
:Real(666,X,Y,12,2
-
Oh, I meant that if you wanted to display a string like "HELLO" it would be displayed as
H
E
L
L
O
Then with for treating the string as a 2D array, a string like "012345678" with width 3, reading the first 'column' would give you "036". For a text-based tilemap, this means you could shift the screen right and only have to draw a single column of text instead of redrawing all of the text on the screen. I think this is more practical for the non-color calcs, but I don't know how much faster it is to shift the screen left/right versus just redrawing the text.
-
By the way will it be possible to edit the sprite data from our games either by individual pixel or chained math operations or variable replacement? It would be nice to be able to do things like this without having to use 4 copies of the same sprite with only colors as difference:
(http://img.ourl.ca//burningtreeoflife-1.gif) (http://img.ourl.ca//rainbowtreeoflife.gif)
This was an animation technique frequently used in SNES games during magic animations, such as fire, to make it look more like the boss is burning without too much additional effects. Of course I would be fine by using multiple sprites with a modified palette, but it takes more space.
-
This could be possible, but im not sure what the best way to implement it is.
Ill have to have a think about it. Looks cool tho :).
-
I guess for now I'll just use 4 sprites lol. The data can always remain archived, right?
-
Very sadly i lost the last 3 major updates to this project, which means that i have lost a LOT of progress.
It is very distressing and depressing that i am now going to have to rewrite all of that *once existing* code.
I was making backups of the wrong code :(.
-
Awww I feel so sorry for you. :'(
-
Awww, this sucks. I heard about this on IRC. :/ Hopefully it won't take too long to recode it.
-
That sucks so bad :'(
-
Awww :(
Don't you have a program on you calc or somewhere that you could disassemble to find bits here and there ?
-
Bad, indeed :(
-
This sucks. Hopefully you don't lose interest in this project and I hope rewriting isn't too hard. I hated losing even one day of work on my projects in the past x.x
What updates were lost exactly? The triangle stuff, the sprite routines, text, tilemapper, etc?
-
Yeah i lost large sprites, line drawing, triangles, tile collision routines, multi-movement routines and other stuff.
I should be able to get it back up and running soon, just annoying is all.
-
at least you already know a lot of solutions of problems you ran into before and thus speeding up coding :)
-
True, i might even think of a better way to do some things.
Though a lot of the code will be a rush job, as always :).
-
Yeah i lost large sprites, line drawing, triangles, tile collision routines, multi-movement routines and other stuff.
I should be able to get it back up and running soon, just annoying is all.
Hopefully nothing else gets in the way. Sometimes we discover something then after losing the progress, we forget how we did it. >.<
What were the multi movement routines, btw?
-
The multi-movement routines were functions where you give it your x&y variables and a step size and it will check all arrow keys and move depending on what was pressed. There was another that would also check for tile collisions as well. This means that you can move a sprite depending on what keys were pressed, and if the position it moves to is walkable in 1 real( request. It saves a lot of extra code in your program.
-
Oh that would have been nice. For the collision, is it possible to specify dynamically where the solid tiles end in the spritesheet? For example, if I make a game where later it becomes possible to swim through water and the water tiles are placed in the middle of my sprite sheet, can I use boolean logic to offset the floor tiles starting location by 1?
-
The command takes a max walkable tile argument when you call it. So if you normally have tiles 0-31 and water from 32-37 then you can just set it higher later on.
-
Ok thanks, but can the argument be something like 27+(L1(56)>13) or does it absolutely have to be a constant?
-
Yes that should more than fine :)
EDIT - Also i added support for xLIB BG PIC's which are small res 80x60, 256 colour images that are scaled to fullscreen. These only take up 4800 bytes and could possibly be used for simple backgrounds, titlescreens or RPG battle backgrounds etc.
Here is a demo of a few strung together:
(http://img.ourl.ca//rr.gif)
:D.
-
Lol at the rickroll, but I like the small size (providing they take no ram lol). I was personally thinking about tilemap backgrounds actually, since some maps occur in the sky or stuff. But cutscenes would be nice, not to mention the size is similar to the 84+ so porting older game cutscenes wouldn't be too hard.
-
Yeah, currently the pixels are 4x4 and it is a pretty low resolution image. But with the addition of colour it can be used effectively. I still need to fix a small issue with them but for the best part they are good to go.
I am still wondering about the best way to store tilemaps, im still leaning towards HEX Strings. xLIB will have some support routines to make working with string tilemaps a little easier like:
getTile - return tile at x,y in Ans
setTile - set tile at x,y in tilemap
numToStr - convert number to string in Ans
strToNum - convert string to number in Ans
moveXYCT - adjust x,y depending on keypresses and check for tile collision
Any other ideas?
-
Hex strings are fine, as long as any collision detection can be done with the Gettile command. Else, string collision detection is brutally slow.
-
Seeing this developing, I wouldn't mind play a game with 4*4 pixel if I get a decent framerate!
-
Actually xLIB CSE supports 8x8 pixels. Normally, such calc would use 16x16 sprites but since he uses 160x240 resolution mode (meaning 8x16 sprites) he decided to go with 8x8 sprites that are scaled up vertically. That way also, it makes it MUCH easier to port old monochrome/grayscale games, since all you have to change in graphics is adding colors.
That still makes me wish I never lost those colorized Reuben tiles in 2005. D:
-
Well the bgpic's are 4x4 pixels but you are correct about the 8x8 sprites.
Although you can draw sprites of any size, they are broken into 8x8 tiles when defining them.
I have managed to bring the code back up to speed since the data loss, and it is appropriately backed up :).
So far the list is:
Tilemap 8x8, 256 colour tiles, tiledata stored as strings
Sprites any size, clipped with transparency
Custom tile/sprite pic's, 128x64, 256 colours stored as appvars, unlimited number (custom named), can be archived
Custom 'bgpic' 80x60, 256 colours stored as appvars, unlimited number (custom named), can be archived
getTile returns tile in Ans
getKey with flexibility routines, can test for multiple keys in 1 call, can check for tile collisions etc
User variables, 256 * 16-bit variables (or memory slots) that most functions utilise (can still use TIOS for calculations etc but will need to store in a user variable for some routines)
Planned:
Text routine
Line & shape drawing
ExecuteArchivedProg (just a copy+paste from old xLIB really)
More getKey support routines
Sprite collision routine
Other stuff ...
Now that I have some basic functionality, ill see if I can make a decent test program.
-
Will rectangle drawing use a different routine than other shapes to save speed? Also can tilemap data (the one in appvar format) be archived and read directly from?
-
Add shape collisions and transformations such as rotation and resizing :)
-
Tilemap data is in strings only, there is no appvar tilemap data. I thought that this was the consensus?
What i would do is have a program containing a full map and then you can create strings from it when needed.
I can look at shape collisions and transformation/rotation etc, but that might not be until a future release :).
-
Wait, I thought map data was in appvar format like Axe unless in use, in which case it was string-based? ???
IIRC your goal was originally to eliminate any need for program copying (archive to RAM) and the need to split map data into multiple sub-programs to temporarily fit in RAM at all.
If it's always in string, do you think the basic data could use base-37? That way each tile takes 1 byte (0 to Theta) instead of 2 (00 to FF). D:
-
... base 37? Or do you mean 4-bits per tile? (So 1 hex character).
I thought I had asked everyone their thoughts and everyone seemed to agree on TIOS strings with hex chars @ 2 bytes per tile.
How would you dynamically change tiles (like remove obstacles etc) if your data is in FlashROM?
-
Base 10 would be 0123456789
Base 16 would be 0123456789ABCDEF
Base 37 would be 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ and Theta.
Else maybe an higher base, where after Theta, we use Sin(, Cos(, Tan(, Ln(, log(, etc. (as long as those tokens are 1 bytes)
Also I think there was a misunderstood. People including me thought you meant an ASM hex string stored into compressed appvar (where each tile takes 1 bytes), not BASIC strings where one tile is made of two hex chars (due to not being squished with the AsmPrgm command) and thus, takes twice as much space. And I myself have never ever agreed with entirely string data, since I thought it was too massive (twice larger than ASM hex). Since you seemed relunctant about letting us dynamically change tiles such as obstacles in Flash ROM data, I thought it meant the map data would be stored in ASM and that for obstacles we would simply use a second copy of the map or hard-code some stuff.
Anyway, since it seems like you are going with the old school way of storing maps, I think we should stick to it now (Basic strings, that is). But still, if one map can have up to 256 different tiles, then each tile ends up taking two bytes, because they are made of two chars (eg 4B). Hence why I suggested Base 37 (I doubt someone would need more than 37 tiles in a single map). Not sure how hard it would make it to convert maps, though, plus it would not let the user use the entire sprite sheet at once x.x.
Anyway you haven't been very clear in general so far during explaining of xLIB features and how they work (no offense), so it might be best to wait until it's out then write a good readme explaining the syntax and what each arguments are, like the old xLIB readme did. Else there will just be too many misunderstoods and confusion (or maybe false hopes).
-
Oh ok, I thought you meant base-37 as in a number system, not that you could have 37 characters to represent a tile.
The main reason why strings are used is because you can manipulate them with the TIOS. This means that you can do whatever you want with them and not need to wait around for someone to write an ASM lib just so you can copy data around. And people can make map editors in BASIC as well. Of note, the Zelda test map I used has 124 unique tiles, though I'm pretty sure you meant more than 37 tiles on 1 screen?
And 2-byte hex strings is still 4 times smaller than matrix elements, if that counts for anything :).
How about a 'squish/unsquish' function to encode the data in a string to 1-byte per tile?
-
Unsquish/squish would definitively be a great addition. :)
-
Yes that should more than fine :)
EDIT - Also i added support for xLIB BG PIC's which are small res 80x60, 256 colour images that are scaled to fullscreen. These only take up 4800 bytes and could possibly be used for simple backgrounds, titlescreens or RPG battle backgrounds etc.
Here is a demo of a few strung together:
(http://img.ourl.ca//rr.gif)
:D.
Rickroll!!!!!
Also, i guess you finished re-coding your lost code?
-
Yeah pretty much, plus i hope i have coded things a little better this time around anyway :).
I have also added a 'replaceTile' function which will search a tilemap string and replace the specified tileID with another. Can be useful for easy 2-frame tile animations.
-
wow, cool, does that also work that you'll say like, i only want the first 2 tiles replaced or is it always replacing all of 'em (to be honest, i can't find of a practical solution for my szenario right now >.<)
-
At this stage its the whole map. You can still modify individual tiles with 'setTile' if you need to replace only specific tiles i guess.
I making a small proof of concept demo to try and demonstrate the features thus far ... (and to see if xLIB on the 84C is even feasible for games!).
-
yaaaaay/me expects DJ to make some epic RPG in 2 weeks using xlib
-
I hope it's feasible for games lol. That said, having seen how fast the Zelda screens are, I bet it will. For an RPG, you need at least 2 FPS during character movement in a map engine, including collision detection and stuff
-
Yeah pretty much, plus i hope i have coded things a little better this time around anyway :).
I have also added a 'replaceTile' function which will search a tilemap string and replace the specified tileID with another. Can be useful for easy 2-frame tile animations.
That's pretty sweet. ^^
-
Here is a small tilemap test. There is 8-directional movement (arrows+combos) and tile collision checking, the sprite is moving 8-pixels at a time.
The animated tiles are 2 frames and take advantage of the way xLIB uses GRAM, meaning that they dont require any extra processing once drawn.
Im working on making some more routines to speed things up if possible.
I apologize for the crappiness of the video and the fact that i did it on my phone just before leaving for work.
Here are some screenshots of the map:
(http://img.ourl.ca//1.png) (http://img.ourl.ca//2.png) (http://img.ourl.ca//3.png)
-
Looks nice Tr1p! :D
-
Wow I didn't realize that animated tiles would be possible with the swapping between buffers, since I thought that the character would keep flickering or something when walking around. I assume that makes any HUD slower to display, right?
Anyway this really looks great and fast. *.* Btw how does the code look like? I am curious how large it is with this version of xLIB, especially collision detection.
Also nice sprites :D
-
Thanks, the sprites ive just been messing around with, but im pretty happy with the pine trees lol.
Yes to fully update a HUD you will be required to draw it twice.
The code for this demo, ive only been rushing through it so optimisation tips are welcome :).:
:real(0,1,0
:"TESTTILE
:real(5,0,0
:real(1,1,0,80
:real(1,1,1,8
:real(1,1,2,8
:real(1,1,3,8
:real(1,1,4,0
:real(1,1,5,0
:real(1,1,6,40
:real(3,0,4,5,6,9,0,0,19,14,1
:real(3,3,9,2,62,63,60,61
:real(3,0,4,5,6,9,0,0,19,14,0
:real(3,3,9,2,63,62,61,60
:Repeat real(2,0)=15
:If real(1,0,4)≠real(3,4,real(1,0,0),20) or real(1,0,5)≠real(3,4,real(1,0,1),15)
:Then
:real(1,1,4,real(3,4,real(1,0,0),20
:real(1,1,5,real(3,4,real(1,0,1),15
:real(3,0,4,5,6,9,0,0,19,14,1
:real(3,3,9,2,62,63,60,61
:real(3,0,4,5,6,9,0,0,19,14,1
:real(3,3,9,2,63,62,61,60
:End
:real(4,0,0,1,1,1,‾8real(1,0,4),‾8real(1,0,5),248,1,0,125
:real(4,0,2,3,1,1,‾8real(1,0,4),‾8real(1,0,5),1,0,0,real(3,1,2,3,6,9,0,0
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
:real(2,4,0,1,8,8,6,19,9,0,0,7,7
:End
:real(0,1,1
Here is a brief explanation of the code:
"Enable 160x240 mode
:real(0,1,0
"Load appvar tilePIC called "TESTTILE into memory slot 0
:"TESTTILE
:real(5,0,0
"Create player X,Y and tempX,tempY user variables
:real(1,1,0,80
:real(1,1,1,8
:real(1,1,2,8
:real(1,1,3,8
"Create map X,Y,MAPWIDTH user variables
:real(1,1,4,0
:real(1,1,5,0
:real(1,1,6,40
"Draw tilemap (uservar 4,5,6) to current GRAM buffer and switch GRAM (updateLCD)
:real(3,0,4,5,6,9,0,0,19,14,1
"Replace flower animated tiles in tilemap with 2nd frames
:real(3,3,9,2,62,63,60,61
"Draw tilemap (uservar 4,5,6) to current GRAM buffer (since we switched)
:real(3,0,4,5,6,9,0,0,19,14,0
"Replace flower animate tiles to original frames
:real(3,3,9,2,63,62,61,60
"Main loop (until player presses CLEAR
:Repeat real(2,0)=15
"Check if player X or Y is a different screen multiple than the current map X/Y (walked to a different area)
:If real(1,0,4)≠real(3,4,real(1,0,0),20) or real(1,0,5)≠real(3,4,real(1,0,1),15)
:Then
"If so then store new map X/Y and redraw map, replacing animated tiles as before
:real(1,1,4,real(3,4,real(1,0,0),20
:real(1,1,5,real(3,4,real(1,0,1),15
:real(3,0,4,5,6,9,0,0,19,14,1
:real(3,3,9,2,62,63,60,61
:real(3,0,4,5,6,9,0,0,19,14,1
:real(3,3,9,2,63,62,61,60
:End
"Draw main player sprite at player X/Y (uservar 0,1) and switch GRAM (updateLCD)
:real(4,0,0,1,1,1,‾8real(1,0,4),‾8real(1,0,5),248,1,0,125
"Redraw the tile at temp X/Y (uservar 2,3) that the previous player sprite was over to restore the tilemap
:real(4,0,2,3,1,1,‾8real(1,0,4),‾8real(1,0,5),1,0,0,real(3,1,2,3,6,9,0,0
"Copy current player X/Y to temp X/Y for use in next frame
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
"Get keypresses and move 8 pixels in X/Y, check that there are no collisions with any tiles >19 in the tilemap
:real(2,4,0,1,8,8,6,19,9,0,0,7,7
"Loop
:End
"Restore LCD to 320x240 mode
:real(0,1,1
-
Wow, almost no more BASIC in the code O.O
ANyway this seems kinda small, which is good. Also after the IRC discussion, I'm glad that maps can be larger than 20x15, because when my RAM allows it, this could make it easier for collision detection on map edges (since I could overflow outside of the currently displayed map instead of wasting two rows and two columns per map chunk).
-
Yeah there is a lot of calls to real( hehe. That said, you can still use TIOS vars and BASIC code, just some functions require you to store the results in xLIB uservars first. But i might change this so that it can be the same as old xLIB as well.
-
That reminds me, can the map be something like 13-14 pixels high? Just wondering if HUDs are possible.
-
You mean tiles high?
You can draw a map from 1x1 tiles to 20x15 tiles (fullscreen) at any position on the screen. The tilemap command takes:
XSTART,YSTART,XEND,YEND
Which is how you specify what size and where to draw the map.
For a 16 pixel high HUD at the bottom of the screen you can set it to: 0,0,19,12
If that makes sense?
-
yeah I meant tiles high, my bad. And yeah I was wondering if it was possible to display maps that don't cover the entire screen height, like those 20x14 maps:
(http://img.ourl.ca//nemesiatx.png)
-
Yep ill mod the example to demonstrate when i get home :).
-
That's good to hear then. :) If I decided to use scrolling for any reason, I prefer not having to redraw the HUD every frame. :P
-
Wha, that tilemap is looking awesome!
It is actually faster than reuben quest (the non-axe of course) :P
-
tr1p you should add a command to enable/disable low color mode, like that routine AssemblyBandit made. It turns the calc into 8 color mode, supposedly to save battery life, but combined with screen inverting, this would make very nice commands for magic animations. I just tried mashing both F1 and F2 keys in IViewer and the result was pretty cool. :D
-
It looks soooooo good :D will you make an ASM lib out of XLib functions ?
EDIT : 1000th post !
EDIT 2 : does my sig fit the rules like this ?
-
EDIT 2 : does my sig fit the rules like this ?
There are no finalized rules yet, and the topic sig rules died so quickley that i don't think there are any real sig rules.
-
Well xLIB by itself will be an ASM lib for BASIC programmers. Actual libs made using xLIB+BASIC would be kinda inneficient, although I guess if people creates map engines or menus, they could post them on ticalc.org for other programmers.
On a side note, by low color and screen inversion routines that are built-in the calculator, this is what I meant. On a real calc it doesn't look too flashy at least:
(http://img.ourl.ca//treeoflifexlibmockup.gif)
The low color mode alone could be used for certain magic animations that requires intense colors, while the other, perhaps combined with the low color mode, could be used for lightning bolt spells, for example.
-
epilepsy warning :P
-
yeah i can enable 8-colour mode easily enough, its just a few lines of code.
Can make for some crazy stuff lol.
-
It's looking too awesome. O.O
Though I stil want an HP Prime first. :P
-
Indeed. Also I want an HP Prime but I think an Omni member living in USA will have to buy it for me then ship it to me, since no US store seems to ship them in Canada and every European store are overpriced (like $50 more than in USA).
Also I had in mind to port some of my future xLIB games to the Prime.
-
Same like you streetwalker, but the moneys.....
-
Same like you streetwalker, but the moneys.....
If it's around €150, then I already have 2/3 of it. :D Just wait for Christmas (also my bday is january 4th so yeah, not long to wait). :P
But let's not derail this topic. ;)
-
If only shipping wasn't that expensive... in Canada there were two 84+CSE sales with the calc at $129.99 and $139.99 at two places (before taxes), which would have been like €90. I bet in USA it was even cheaper.
Anyway I hope that xLIB comes along nicely right now. :) I have begun getting as many sprites and tiles as I can for future use. Hopefully I can cram as many as possible in the sprite sheet space. :P
-
I have implemented drawLine and drawRectangle (which just uses drawLine :)). I havent tested drawing offscreen that much but it should work.
Simple screenie of a basic program randomly drawing rectangles...
(http://img.ourl.ca//1378917087.gif)
Now to do fillRectangle!
-
ooh this will be useful! Also I'm glad that you are adding filled rectangles as well. :)
-
ha, looking nice!
-
Stop making me want this thing :(
-
DJ suggested that i implement a RAND function since the TIOS Rand is reputed to be quite slow. It will give you a random number between 0 and the upper bound you specify (<=255).
I did a rough test drawing 1000 rectangles, TIOS came in at 1m57sec, xLIB was 52sec which is enouraging.
Here are 2 screenies side by side drawing 100 random rectangles. Left is TIOS Rand, right is xLIB Rand.
(http://img.ourl.ca//1379001917.gif) (http://img.ourl.ca//1379000607.gif)
-
Yeah. To explain how slow the TI-OS one is, it is often used as a replacement to For(Z,0,25:End to save a few bytes. I got the idea for an xLIB one only after noticing the rectangles were a little slow-ish, though.
-
Yeah. To explain how slow the TI-OS one is, it is often used as a replacement to For(Z,0,25:End to save a few bytes. I got the idea for an xLIB one only after noticing the rectangles were a little slow-ish, though.
Lol ? That's awful ! D:
-
Here is a demo of the screen shift function, used for a simple earthquake effect.
-
Wha, that is so epic, i love the speed, also, yay for new rand function :D
-
Very nice, but is it me or does there seem to be a shifting bug during map transitions? ???
-
Yeah there was a little bug in there that has since been fixed :).
-
For the fillrect routine, do you just define the window and write the same two bytes over and over? I imagine you would make the A register the height, then DE contains the values to write, HL could be the width and use the increment mode going down:
ld c,11h
dec hl
inc h
inc l
fillloop:
ld b,a
fillloopinner:
out (c),e
out (c),d
djnz fillloopinner
dec l
jr nz,fillloop
dec h
jr nz,fillloop
ret
I am not familiar with the extreme tricks yet :/
-
A pxl-on command would definitively be nice, for when we just want to change the color of 1 pixel. :P
-
Oh yeah, there is setPixel and getPixel as well. There are 2 versions of these routines, ones that set one of the standard 256 colours, and ones that set 16-bit colours.
-
Ok thanks. Glad to hear :)
-
So there are:
getPixelA - 16-bit colour
getPixelB - standard palette 256 colour
setPixelA - 16-bit colour
setPixelB - standard palette 256 colour
drawLine - standard palette 256 colour
invertLine - inverted line on LCD
drawRectangle - standard palette 256 colour
invertRectangle - inverted rectangle on LCD
fillRectangle - standard palette 256 colour
fillInvertRectangle - inverted solid rectangle on LCD
-
Seems cool. How will the 16-bit mode work? Also do you still plan to make the full screen inverting use LCD routines?
-
Sounding awesome!
I just can't wait to see all the epic games arise using xlib ::)
-
Well 16-bit just takes 2 colour arguments instead of 1 and will enable you to draw from the full spectrum of colours available. Im not really sure how useful it will be since its only pixels.
DJ: Yes the fullscreen invert is available as well.
-
Cool to hear. :D By the way do you plan to release xLIB before Doors CSE merges with it? It would be nice if maybe we could start developing games before the merge, in case, for example, Kerm got too busy during school year and that it took one more year before the merge happens.
-
Yes i plan on writing 1 more function before releasing it for testing and stuff.
The code will be available to Kerm so this time the same codebase will be present in xLIB and DCS, which should take care of any compatibility issues.
-
Ok that's good to hear :) I was worried that the recent announcement about the merge would delay xLIB 84C release and cause interest to wane with the time (like the HP Prime late release). D:
-
yay, release is soon!/me gets ready for looking at epic game dev of other people, sadly i don't have a 84C :/
-
Yes i plan on writing 1 more function before releasing it for testing and stuff.
The code will be available to Kerm so this time the same codebase will be present in xLIB and DCS, which should take care of any compatibility issues.
@tr1p1ea
That sounds great! :D
@Sorunome:
* Art_of_camelot gives Sorunome (1) 84C*
84C in this case means a TI-84 Cookie. Item is virtual and non transferable some limitations may apply...
-
I didn't have much time to test the beta, sadly, because it was released in the middle of my busy weekend (where I work for the most part) and I was exhausted. I got some days off lately, but now I am pretty sick (huge cold), with my usual stiff neck issues, meaning I can't really sit down for an hour coding nor concentrating.
However, I did spot one bug so far when testing ADEMO.8xp: When you exit, 320x240 mode isn't setup properly. Also, I noticed that even if I add an i:Asm(prgmLCDTOOL after the program, even that standalone program by Calc84maniac won't change the calc back to 320x240 mode. I have to run it manually to do so.
-
Can you check the last command in the demo, it was corrupted with a ?, change to a 1 and it should work.
-
Ok thanks it worked now :D
Actually, though, it was an empty char, not a ? ???
Also the result makes me wish this calc supported homescreen backgrounds O.O (although I bet that would be kinda slow)
-
New bugs report:
-SETGRAMOFFSET does nothing at all. (syntax used= real(8,1,10). I also tried with both TI-OS and xLIB Rand functions)
-Text doesn't switch GRAM/update LCD
-Text also doesn't support variables nor things like randint or xLIB rand as arguments. Only constants can be used.
-When updating the LCD it seems that it isn't aligned properly.
-Rectangles takes 2 seconds to appear O.O
-
Ill investigate and revert back, there is a new version that fixes the SETGRAMOFFSET problem.
Do you have inputs for the others, particularly the rectangle example?
-
This is my program as of the other day (which now uses real(0, 6, 7 and 10):
real(0,1,0)
real(7,9,0,0,160,120,0,0) //The part that takes 2 seconds
"HELLO/WORLD
For(Z,0,25
real(6,0,Z,25,3,"/",1) //If I used variables for the text location or color, no text appeared. Also even if changing the last 1 to 0 text only remains on one GRAM side. Also newline char doesn't work.
real(10) //WARNING: SEIZURE!
End
real(0,1,1)
-
tr1p1ea could you re-send me the update you sent me last night? Because I use Windows 7 and TI-Connect version 4.0, and I can't get it to recognize the copy of xLIB that you sent me as a 84+CSE application. Could you just re-compile it in the same format as the previous build? (xlibc.8ck, kinda like AssemblyBandit's and Kerm's apps)
-
Thats very strange since the assembling has never changed, and the file sends+installs to my calc?
it is in the same format.
I will see what i can do.
-
Well the previous version was called xlibc.8ck, while the other one is called "xLIB - TI-83 Plus (Application).8xk". Now there are even two copies of "xLIB - TI-83 Plus (Application).8xk" in the compressed archive.
You could maybe ask AssemblyBandit what compiler does he use for his apps, to ensure that you have the best compatibility options. It's also possible that you got a different calc hardware (mine has no letter at the end of the serial number, meaning it's an original model). Else I'll probably have to end beta-testing xLIBC until the DCS merge or until Kerm recompiles it for me. D: (I don't want to get a new calc)
Basically TI-Connect just lists the app as Incompatible Type and the Send button is grayed out. Even changing the extension manually from 8xk to 8ck won't solve the problem.
-
Are you sure it was .8ck, ive never used that extension (there is no official extension). The APP transfers and works fine on my calc.
There are no options for compiling APPs for the 84C - its the same as the 83+ with the signkey field updated.
Its possible that my web host has corrupted something?
-
Yeah the previous one was 8ck.
And I definitively think it's your web host, since the previous build came with two corrupted files (ADEMO had a missing char at the end and the map file didn't send). It could be compatibility issues between .7z and Winrar, tho.
-
Question, how do we detect if the screen is inverted or not? Currently, xLIB just toggles between both mode using the same command, but that can pose some issues if somebody exits the program from the wrong place and the calc ends up in inverted mode, since when the game will be ran again there's no way for xLIB to detect in which mode it is.
-
I can make the function return what the status of the screen is in? 0 = normal, 1 = inverted?
-
That could work.
Also bug reports for the new xLIB version you sent me:
-Text still isn't fixed (the same bugs are there, meaning it doesn't properly update GRAM location.)
-15 MHz mode doesn't work. I tried in both 6 and 15 MHz mode and both the demo and my little program still runs at half speed (with full screen rectangles taking 4 seconds to generate instead of 2.)
Also, something I noticed is that in the ADEMO.8xp program that came with the other xLIB version, when you exit the map it doesn't switch to the next map anymore. I wonder if that is due to a syntax change like the 160x120 mode setup?
-
Yeah sorry i need to update the demo :S!
Also i will test the other functions and see whats up.
Thanks.
-
By the way, will real(10) and text LCD updates be fixed in the next DCSE release? So far I still have the following issues:
Real(10): Does nothing at all
Real(6 text:
-In most cases, Only displays text on one LCD area without updating the other side in most cases.
-In one case where I got it to work (such as using a constant rather than variable for text location), some chars changed the background pixels color and pixelates down the background to 160x120. This seems to only happen on TI-OS backgrounds, though and the green in the battery indicator isn't affected as much. Is it due to the xLIB palette? I am concerned this might cause some conflicts with Celtic II and pure BASIC commands.
-Also, one extreme annoyance is that real(6 returns 0 to Ans. Basically, if we need to display the same text multiple times, such as an animation or shadow effect, then we have to store it to a string first, then store it to Ans over and over, which slows things down a lot. Would it be possible to make the command not return anything to Ans?
Inverting pixels seems to have the same problem with LCD update. Always remains on the same side.
xLIB ran in 6 MHz mode no matter if real(0,2,0 or real(0,2,1 was used.
Another thing I noticed is that when in 320x240 mode, sprites/tiles displays as garbage.
By the way, how would someone scroll through the screen? Normally it would have been While 1:For(Z,0,319:real(8,1,Z:End:End to loop through it, but since that doesn't automatically update the screen offset and that real(10) doesn't do anything at all, this makes pretty much any smooth scrolling or earthquake effects impossible.
-
Im hoping that it will be fixed, in the interim are you able to send me the exact programs that you are using that is causing trouble? Or even the code so that i can replicate the problem?
-
For real(10) I had this happen with every xLIB command or alone. It just failed to switch GRAM areas.
As for text failing to update GRAM too, I discovered why: It's because real(6 stores 0 to Ans, overwriting my string. The problem would be solved by making real(6 no longer return anything to Ans. It would solve many other problems too.
As for text changing some background colors if drawn over TI-OS material, it's most likely because xLIB uses 160x120 scaled up 2x and 256 colors instead of 320x240 with 65536 colors. I don't think much can be done about that. I never had the problem happen when drawing text over xLIB sprites/backgrounds/other text. It could definitively get in the way for certain programs utilizing TI-OS and Celtic drawing, but it could actually possibly become handy for special effects in the future. :P
Regarding InvertPixel failing to update GRAM area regardless of if using 0 or 1, here's the code I used:
real(0,1,1,0)
While 1
real(7,4,0,0,1)
For(Z,0,100:End
End
The 6 MHz issue is pretty much self-explanatory. The xLIB commands runs at 6 MHz by default no matter the real(0,2,mode syntax used.
For the garbage sprites/text issue, just remove the 160x120 res command at the top of ADEMO.8xp and see what happens.
For LCD Offset failing to change, this is my code:
real(0,1,1,0)
While 1
For(Z,0,319
real(8,1,Z)
End
-
Ok i have fixed a lot of bugs.
BUGFIXES:
---------
DRAWSPRITE transparent background now works for 16-bit colour backgrounds
DRAWSPRITE now sets and restores the LCD entry mode independently (can be used without 160 mode set)
DRAWSTRING stringlength fix (needs verification)
DRAWSTRING newline character fix
DRAWSTRING no longer destroys ANS
DRAWSTRING inherents DRAWSPRITE entry mode fix
SETGRAMOFFSET changed so that it independently alters the LCD (no updateLCD) *REQUIRES 160 mode to be set
DRAWMAP_GETSECTIONB fixed so that it reads uservars properly
DRAWSPRITETILEBGA/B fixed added x/y offset arguments before tile check
DRAWFILLEDRECTANGLE clipping boundry fixed
Also note that some of your issues were due to outdated documentation in the wiki (like the missing SIZE argument for get/set/invert pixel :S) that was also causing you some issues. Kerm has an updated version of the code so hopefully people have more luck with RC2.
I have tested DrawString and the LCD offset examples and they seem to work ok. Note that LCD Offset will only work while the calc is in 160 mode.
Drawing sprites and strings now works on the TIOS as well (without the need for 160 mode).
-
Wow that's cool to hear. By the way was the DRAWSTRING string lenght issue why I sometimes saw an extra ?Dec or something at the end of my strings? I noticed it once I think but I thought I just did some mistake since I didn't have it happen with very small ones like HELLO/WORLD. Also what does inherents DRAWSPRITE entry mode fix mean?
Glad the text command no longer stores to Ans btw. :) Will DRAWSTRING now accept TI-OS vars for X, Y and Color?
Also glad to see this SETGRAMOFFSET fix :). I am curious about what kind of stuff could be achieved by using it and by switching active GRAMs in ways that are not meant to be :) (I'm not getting my hopes up due to the nature of TI-BASIC and my lack of knowledge in xLIB sprite functionality, but we never know lol)
Are rectangles now faster btw or will they still draw in 2 seconds? Also will 15 MHz mode be set properly?
Also suggestion: Make xLIBC doc more visible on the DCS wiki (although I guess that would go more for Kerm). The only way I could ever find it when I went there was by typing xLIBC in the search box.
-
When i say it inherents the DRAWSPRITE fix i mean that text now can draw over a background as well without the colours messing up (like the statusbar gray etc).
Yes DRAWSTRING will accept TIOS vars for X,Y,Colour, i have just verified this on calc and in jsTIfied:
(http://img.ourl.ca//1382636173.gif)
Note that 160 mode isnt supported, but the updateLCD flag is set so you can see it switching between GRAM areas each frame.
SETGRAMOFFSET only works if you are in 160 mode, otherwise it will do nothing. You no longer have to specify whether you want to updateLCD or not, it just shifts the screen. I have tested shifting both ways on calc and it appears to work ok.
Rectangles are now very fast and will draw in a split second, i have also included a FILLSCREEN function which will fill the active GRAM side with a colour fromthe xLIB palette.
Im sure Kerm will promote the wiki when DCS is released :).
-
Ooh ok, I didn't know what "inherents" meant. Thanks for the clarification.
Also this is an awesome fix. I always wanted to be able to use variables to draw text in case I do animations or need to generate a menu or something. As for 160 mode not being supported, will this be fixed in the next release or will text only be useable in 320x120 mode from now on?
Glad to hear about the rest! :)
-
Oh sorry i mean that jsTIfied doesnt support 160 mode! DRAWSTRING works in both 320 and 160 mode! The screenie on a real calc shows it as 1 smooth animation from top left to bottom right, not 2 sides.
However it is confined to GRAM sections so you can only ever draw on 1 side of the screen in 320 mode, if that makes sense.
-
Oh I see now lol. By the way we can really decide on which section of the GRAM we want to draw, right? This would be handy if someone wanted to make a game using 320x120 resolution for higher details or if screen shifting is used.
-
Please don't double post. This is considered spam and thus impolite. :trollface:/me runs
-
I am surprised this happened, considering I got no connection error O.O. Must have been the forum spazing out.
Also tr1p1ea I tried DCSE RC2 and WOAH xLIB rectangle speed is ridiculously fast now!! *.* (also variables usage in text argument works now)
-
Yay!!
Glad that its working faster now, you can set which side to draw to GRAM by using the SetLCDBuffer function. You can set it to either 0 or 1. This can make it so you can draw to the nonactive (the part that you can see) side of GRAM.
-
Thanks, so Mario would be possible? *.*
Also real(8,2,offset works now :D.
EDIT: Bug report: Real(10) still doesn't work. Nothing happens at all:
real(0,1,1,0
While 1
real(10
End
Also I was wondering if there would be a way to add a real(8,2,x command that is completely independent from active GRAM buffers?
-
Ill test this when i get home, it works fine in my debug build of xLIB. I will have to wait until i get home to try out RC2.
Also Mario is always possible, i have a small demo that i made months ago. I think AsmBandit is working on it though?
-
Weird.
Also another bug report: There seems to be some Getpixel lag occuring. If, for example, I fill the entire screen with a low value color (such as black), then draw light stuff afterward, Getpixel will still return the original black value. I am unsure why this happens, but basically I had a splash screen with a black background, then overwrote the entire screen (both GRAM buffers) with the road, yet it still returned the title screen bg color as getpixel value. I was using GetpixelB (xLIB palette). ???
-
wow seeing xLIB on a ti 84+CSE really makes me wish i've had one... :(
(although personally i like programming axe better than xLIB but that's just me)
-
Yeah the issue is that with xLIB, due to the weird real commands, you always need to carry a copy of the instructions with you when coding because it's impossible to remember commands by heart.
-
Even with ASM programming I need to look stuff up all the time and those instructions make more sense than just numbers. I hope more games will come out for the CSE soon. Once I got a 3ds, new pc and an hp prime I might consider buying a CSE :)
-
yeah, i'm still learning axe, so i need my copy of commands all the time too.
but it was noticably present when i tried programming with the Doors CS SDK
-
Yeah at first I had this happen when I coded Axe, but the syntaxes are much shorter and verbose in general than just a big bunch of real commands and full of numbers. That said I find BASIC and its libs easier when it comes to external save data management.
EDIT: Feature suggestions besides the movable GRAM buffers and full screen buffers (well, rather getting rid of them as an option):
-Inverted circles and inverted filled circles.
Also question, can the sprite appvar be archived and how many xLIBC vars can we have in total? It would be nice if we had 999 vars or more.
-
I had some issues with circles but I can look into it.
Yes the appvar can be archived and there are 256 uservars. Sadly 999 of them would take 1988 bytes.
-
Ah ok I see. I was hoping for maybe more vars since otherwise I would need to rely on a 9 KB large (temporary) list >.<. I might have an idea, though.
-
One bug I forgot to mention is that the real(0,3,3 command does the opposite of what it's supposed to do. Instead of setting the LCD to a non-inverted state like the description claims, it actually sets it to inverted mode.
Also feature suggestion: A different text command that allows you to display variable content (TI-OS real vars and xLIB ones). Having to convert vars to string is a major hassle and isn't very fast >.<
Also sprites are pretty fast it seems. :D
-
Ok cool ill check out the colour restore, hopefully its something simple.
And yay at least sprites are not dreadfully slow :X!
Did you manage to get the large sprite working? (((((((((Is there any progress on that program you were hopeful of making?)))))))))
-
Yeah I got it to work. I used both versions, but yeah mine had wrong colors so I used yours. You should write some sort of tool that automatically remaps bitmap colors to xLIB ones, like some softwares can do, so we don't have to switch to different softwares (I don't like GIMP and don't use Photoshop/etc). I don't want to make you have to convert every sprite I'll make for me >.<.
As for the program itself, one major hurdle is that there are only 255 user vars, so I might be forced to use TI-OS lists and the game will require almost the entire RAM to run. >.< (I need about 700 elements, although with TI-OS lists I might be able to cut this down by half by using decimals). I could always shorten my levels, though.
-
I guess i can try to match colours to xLIB ones, it may result in quality loss to images however. The best way for me to do it will be with nearest colour i think.
-
Yeah nearest colors would be the best. I don't mind the quality loss btw (although I assume that converting images with lots of gray will be a problem, since xLIBC palette has no gray)
-
By the way I got maps to work, so that's good. One nice feature would be a fill command to draw a tilemap made of just one kind of tile. Right now here's what I am using:
"0808080808
Ans+Ans+Ans+Ans
Ans+Ans+Ans+Ans+Ans
Ans+Ans+Ans->Str0
For(Z,0,1
real(3,0,0,0,20,10,0,0,19,14,1
End
This fills the entire screen with sprite 08, but as you can see, that requires plenty of string concatenation at the start, so it isn't super fast. (Not to mention the TI-OS glitches that can occur with string concatenation). It would be cool if we could just do something like this instead:
real(3,8,MAPWIDTH,XSTART,YSTART,XEND,YEND,PICINDEXSTART,TILEID,UPDATELCD):
Which would give
real(3,8,20,0,0,19,14,0,8,1
Or maybe:
"08"->Str0
real(3,8,X,Y,MAPWIDTH,XSTART,YSTART,XEND,YEND,PICINDEXSTART,PICINDEX,UPDATELCD)
-
Question:
In which order are sprites chained? For example, if I want to draw a character that is not aligned with the tilemap and need to redraw the 4 tiles behind it, in which order should I draw the ball? Should it be drawn first or afterward? Just making sure in case chained sprites are displayed in the opposite order.
The best thing would have been if there was a clipboard feature in xLIB to copy a 8x8 chunk of the screen, so that it makes it much easier to erase character sprites that are not perfectly aligned with the 8x8 grid.
-
Ill have a look into the fillscreen with sprite feature, though i cant make any promises at this stage.
Sprite chaining just draws whatever list you pass to it in sequential order.
Restoring backgrounds should be done on 'old frames' as a way to prepare them for new drawing etc. the drawSpriteTileBG will take care of aligning tiles to their position on screen ... or are you talking about tiles that arent locked to 8x8 chunks of the screen (like you are drawing your own sprites for tiles?)
-
Oh I mean that my sprite (the character that is moving around) isn't aligned on the 8x8 grid. I worried that I would need to redraw all 4 tiles behind it every frame, and knowing that this calc is a bit slow to draw stuff due to the slow processor, I wanted as less stuff to be redrawn as possible each frame.
Also a bug report: real(1,2 and real(1,3 doesn't do anything and displays the wrong value D:. For example, in the wiki:
AddToUservar
real(1,2,Uservar_Num,Value): Add Value to the value of the given Uservar
SubFromUservar
real(1,3,Uservar_Num,Value): Subtract Value from the value of the given Uservar
However, if I want to modify uservar number 127 and add 2 to it every loop, instead of displaying its new value, it just displays 127. O.O
real(1,1,127,50
For(Z,0,150
real(1,2,127,2
Output(1,1,Ans
End
Or could the wiki info be outdated? ???
-
Hi DJ, the add/sub functions dont return the value of you operation, rather they return the uservar number you are modifying.
You need to use the GET function in order to store the number to Ans.
So the code would be:
real(1,1,127,50
For(Z,0,150
real(1,2,127,2
real(1,0,127
Output(1,1,Ans
End
This is because other functions take uservar references, so you can tie them together.
You can optimise the line to:
real(1,0,real(1,2,127,2
-
Yeah I noticed that x.x. That said it might be good to clarify it on the DCS wiki in case more people get confused.
On a side note, how goes bug fixing?
-
Yeah ill be sure to update the wiki once its released. The bug fixing is going well, im nearly there i think :).
-
Good to hear. Hopefully it can come out soon with the official DCSE release. As the 1st 84+CSE shell with xLIBC combined, it should hopefully become mainstream as 84+CSE program, since it will pretty much run every hybrid and ASM game.
Also as seen on IRC, I'm glad you added a load tile into temp RAM feature. For games that only uses a few sprites this should be handy, since we won't be wasting an entire 8192 bytes of RAM just for 12 sprites. :)
-
Yeah that features should be handy although it will take some understanding of how sprites are structured in memory from a data perspective, but i can help out with that :).
Also the conversion tool now does nearest colour matching with the xLIB palette as well.
I have also made the DRAWSTRING_VALUE function return the converted value as a string in Ans if anyone would find that useful.
I am busy testing everything as much as i can prior to release, if anyone has any other bugs etc can they please let me know. Also if anyone just wants to test out random functions to see if they work i would be grateful as well :).
-
Sounds cool. I wonder if returning the converted DRAWSTRING_VALUE to Ans could pose problems in certain situations though? That said, I guess we can just temporarily store the old value elsewhere in case we need it afterward.
So far I found no other bug, btw. I need to try some functions I didn't use yet, though.
-
Tr1p1ea, I found a bug with DrawSpriteBGB D:
:real(0,1,1
:real(5,0,0
:
:"000102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859
:Ans+Ans+Ans+Ans+Ans→Str0
:For(Z,0,1
:real(3,0,0,0,20,10,0,0,19,14,1
:End
:real(1,1,0,76
:real(1,1,1,56
:While 1
:real(4,5,0,1,2,2,0,0,160,0,20,10
:real(2,2,0,1,1,1
:real(4,1,0,1,1,1,0,0,112,1,0,21
:End
Basically, no matter the value of uservar #1 (which I use as Y value), the background will always display the same row of tiles from the tilemap, like if the tilemap Y always started at zero. X works fine, though. When I use TI-OS values, I don't have this problem. For example, the following code works fine:
:real(0,1,1
:real(5,0,0
:
:"000102030405060708091011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859
:Ans+Ans+Ans+Ans+Ans→Str0
:For(Z,0,1
:real(3,0,0,0,20,10,0,0,19,14,1
:End
:real(1,1,0,76
:real(1,1,1,56
:While 1
:real(1,0,0->A
:real(1,0,1->B
:real(4,4,A,B,2,2,0,0,160,0,20,10
:real(2,2,0,1,1,1
:real(4,1,0,1,1,1,0,0,112,1,0,21
:End
???EDIT: Nvm, fixed. It's because map width is an uservar too, but wiki didn't specify that.
-
We spoke on irc about this issue, and at least it isnt really a bug, rather the documentation needs to be more descriptive :embarrassed:.
For others looking on the MAPWIDTH argument also needs to be a uservar reference when calling the B version of DrawSpriteTileBG.
Also HOORAY! DCSE8.0 has been released! Remember, remember! The Fifth of November! :D.
-
Indeed, I was happy when I saw it was out. :D
-
Some clarification:
Real(10 is actually Real(9 since xLIBC merged into DCSE. It was just not updated in the doc. This is why Real(10 didn't do anything. >.<
-
Feature suggestion for the map functions: A mode which supports 1-bit tiles. That way, people who only uses two kind of tiles per map would have much smaller map data. There could be an extra argument allowing the use of three kind of tiles, where you would choose a 3rd tile for walls (rather than just floor and ceiling). Both the ceiling and floor would be 0, while the floor would be 1, and whether a wall or ceiling tile appears would be determined based on if the tile right below it is a floor tile.
Maybe an option to have a cliff tile instead of wall (displaying below the floors instead of above) would be nice too.
Illusiat 6, 7, 9, 10, 11, 12, as well as Mystique and many parts of Mana Force 2 and the Reign of Legends series used such map format and Illusiat 12/Mana Force 2/ROL series used the triple tiles trick. Most maps in those games were stored inside pictures (8xi files), in which each tile were 1-bit.
I would definitively be helpful, otherwise if me or someone was to ever port Illusiat 12 to the 84+CSE, for example, map data would be 8 times larger O.O
-
Note that all xLIBC development from me is now halted until further notice. Don't ask why, I'll just know Friday if it continues or not. For the time being I'll simply focus on bug testing and posting feedback.
-
It isn't really flooding as double (tripple, quadruple, ...) etc posts are allowed if the last post is more than a day ago, which is clearley the way in this case.
-
On a side note tr1p1ea, since xLIB is starting to get old, a lot of younger TI-Z80 programmers are probably unaware of what the original version was, here. So as a suggestion, I would change the topic title to xLIB 84C - fast ASM lib for BASIC programmers or something like that, to attract more people. :P
Wasn't it that you have to put stuff in ans and then call Asm(prmXLIB ?
And nice thingy, the xlib for the cse!
i /really/ should get one...........
indeed you should.
i have one!!!!! :evillaugh:
OH, and omnimaga?( :mad:)
hate to be critical, but what you are doing IS FLOODING.
O.O
since its only fair, pls use the modify button.
As Sorunome said, it isn't flooding. Even if it were, you need to be more polite when saying things to people. Furthermore, you should let staff deal with posts if there is a problem. Thank you.
-
What Soru and Art said. You are beginning to sound trolling/provocative there (since it is the 2nd time in a week). I find it ironic that people who constantly double-post or get warned for spamming suddenly starts reprimanding others for doing the same thing. They should start improving first before telling others what to do.
-
What Soru and Art said. You are beginning to sound trolling/provocative there (since it is the 2nd time in a week). I find it ironic that people who constantly double-post or get warned for spamming suddenly starts reprimanding others for doing the same thing. They should start improving first before telling others what to do.
fine.
-3 my post.
i have never been the popular one.
why dont everyone - this post so i will NEVER get any bloody +s?!?!?
at least someone understands my past.... :rolleyes:
fine.
CLICK THE THUMBS DOWN FOR ALL I CARE!!!! :banghead: :mad: >:( x.x
-
^tantrum. I know I've been a huge meganoob in the past, but at least I changed. DreamDragon, the upvotes or downvotes or reputation counts aren't really significant here. It's mostly just a nice favor. Any upvoting usually doesn't mean much, but a downvot emeans you've seriously stepped over your bounds. Js.
I can't believe it took me this long that there is going to be an Xlib for the 84C :D
-
^tantrum. I know I've been a huge meganoob in the past, but at least I changed. DreamDragon, the upvotes or downvotes or reputation counts aren't really significant here. It's mostly just a nice favor. Any upvoting usually doesn't mean much, but a downvot emeans you've seriously stepped over your bounds. Js.
I can't believe it took me this long that there is going to be an Xlib for the 84C :D
so i over stepped my bounds by simply stating how i feel?
-
Gentlemen, I understand there is a pressing issue at hand but perhaps it could be handled outside of the xLIB thread.
Happy to field any xLIBC related questions, queries or suggestions!
That being said, i really do need to finish my example programs.
-
Gentlemen, I understand there is a pressing issue at hand but perhaps it could be handled outside of the xLIB thread.
Happy to field any xLIBC related questions, queries or suggestions!
That being said, i really do need to finish my example programs.
sowwwyyyy
its just that between my cluttered room and this...
whew its just too much for right now!
-
^tantrum. I know I've been a huge meganoob in the past, but at least I changed. DreamDragon, the upvotes or downvotes or reputation counts aren't really significant here. It's mostly just a nice favor. Any upvoting usually doesn't mean much, but a downvot emeans you've seriously stepped over your bounds. Js.
I can't believe it took me this long that there is going to be an Xlib for the 84C :D
so i over stepped my bounds by simply stating how i feel?
Nah, you can say what you want, but since Omnimaga has rules, it doesn't mean there won't be any consequences. For example, if you say or do certain things to start a fight, falsely accuse people or are being confrontational to members for no valid reason (eg trying to enforce non-existent rules or complaining about downvotes) and you get caught, there will obviously be consequences (starting with downvotes).
Besides, when you are new on a forum and haven't contributed anything constructive yet, it's generally a bad idea to reprimand members who have contributed constructively for much longer than you. We are generally more tolerant about it on Omni, but not if the new member already broke the rules himself several times.
Anyway, this is off-topic, so if you feel that Omnimaga should become anarchy with no rules, you should PM the people in blue or yellow color directly or e-mail [email protected]. Let's discuss about xLIBC now (and especially if it will ever be updated again).
I'm still curious if in the future it will be possible to change the GRAM offsets btw? It would make it much easier to create side-scrolling games
-
Question:
When is using xLIB uservars faster and when is using TI-OS vars faster? Because so far, I spent a long time translating three programs to uservars, only to end up with one running even slower, another running at identical speed and only one improving speed-wise. It would be nice to know when to avoid uservars if we are optimizing for speed, because trial and error might waste a lot of people's time and the fear of having stuff run slower with certain uses of the uservars instead of the other way around might discourage some people from trying them.
-
Bug report: the xLIBC map drawing commands do not work when the map string is archived. In such case, real(3 does nothing at all.
With a smaller string (my original string was 43 KB large so it won't fit in RAM) I tried putting it in RAM and it works fine:
(http://img.ourl.ca/reubencolorwalk.gif)
With it in archive this is what happens:
(http://img.ourl.ca/dcsearchivedstrissue-1.gif)
-
Is that... Reuben Quest? *gasp*
-
Is that... Reuben Quest
yes...in color :P
And it is looking amazing :3
-
Yes it's Reuben Quest. Of course the only thing that was done are sprites, though, and most maps are converted to xLIBC format (although wrongly placed). Considering the many issues I ran into with xLIBC it is unlikely that such game would be available in short terms (unless I separated all maps like they were before). If I keep maps in their previous format, this requires having Reuben walk to the edge of the screen like in Final Fantasy 5 and 6 when he reaches the edge of the map, which is impossible to do in current circumstances (xLIBC bugs or just too complicated/slow to be even viable). The only feasible solution is having Reuben stay in the middle, but this means adding 10 extra rows of tiles on each side of the maps, taking much more space.
EDIT: On the other hand, if I constantly end up with maps full of empty, unused spots, I could just use those spots to store extra game data (for example, the in-game menu layout, battle backgrounds and, if applicable, title screen.) and perhaps even create garbage tilemaps just to store enemy HP/LV/Exp/GP :trollface:
-
What is GP O.O
-
Gold pieces. That's how Gil or Gold in Final Fantasy used to be called, back in the days :P
-
It should be noted that archived strings not working is not a bug, xLIB 84C has never advertised that it works with archived strings - its not meant to.
However, i can look into adding support for it by the next release, since it should prove useful for large maps. This however means that setTile will not work while a string is archived ... but maybe i can look into adding support for that too.
On the other hand, the screenies look sweeet.
-
Aaah I see, I wasn't sure if that was intentionally left out or not. As for set tile I think I would be fine without it, although that could be a problem for boolean maps >.< (speed wouldn't be a problem, because maps only have to be modified when there is an event, not in real time, but it could be hard to implement since it involves writing to Flash I guess).
Also thanks :D
-
By the way, would it be easy to add an extra, optional argument to xLIBC DrawMap so that if a tile ID is outside the tilemap boundaries, it just displays nothing there instead of the other side of the map/garbage? It could be handy for people who want to use scrolling maps without having to add full of extra columns on each side of their map data.
-
It could be possible, but it might be a little tricky ... ill check it out.
-
By the way tr1p1ea, in the following screenshot showcasing the new Rectangle color shift feature (that wraps the color palette around by a value you want)
(http://img.ourl.ca/1398878088.gif)
Is that the actual processing speed or did you add delays to prevent the screenshot from going too fast and skipping frames?
-
Mr. Pumpkin???
-
That is slow due to the way the test is ... its really bad lol:
each frame:
draw sprite
draw fullscreen rectangle with rotated colours
draw fullscreen black rectangle to destroy previous frame
Here is one with just the sprite:
(http://img.ourl.ca/1398934856.gif)
-
Oh ok lol. Now that looks fast :D
Also I think that's a Secret of Mana enemy, right?
-
Ive added support for 32 colour 160x120 images (scaled to fullscreen). These images are 12000bytes for image data + 32 bytes for the palette.
The 32 colours are not predefined and can be made up from a selection of the 256 colour xLIBC palette.
Example images:
(http://img.ourl.ca/1399060418-1.gif)
Looks pretty sweet oncalc and offers more flexibility than the 80x60 bg images without taking up too much size*.
-
Yeah, pretty nice although it would look far better with pixel art. ;) Also, why the * ?
-
The * is because some people might not think that 12kb is a low size for an image :).
Yeah they are just quick image tests, if you were actually designing an image with 32 colours in mind it would look much better.
-
Awesome tr1p1ea :D. This might be handy for some title screens. Also this reminds me Sega Genesis and Game Boy color material.
-
Those image tests look sweet :)
-
By the way, something that would be cool for images if if besides their default palette, you could display that image with a custom palette too. Before calling the function, you would just store a string containing the palette in Ans or Str0 (preferably Ans) and if the function detects a valid string in there, it displays the image using the custom palette instead of the one inside the appvar. It could be handy if someone wants to re-use an image multiple times under different colors.
-
Hhmmm... due to the way xLIBC draws data to the LCD it might prove difficult, but i can look into it.
-
Feature suggestion: Chained DrawShapes.
-
Bug report with xLIBC's DrawSpriteList8x8A command:
If you try to display a sprite and its X position is higher than 128 on the screen, it will not show up. For example, real(4,2,1,0,0,26,1,127,95,0 will work, but not real(4,2,1,0,0,26,1,128,95,0.
-
Nice work DJ i found the issue! I was doing treating the coordinates as 8-bit and sign extending into 16-bits ... this means that 128 gets changed to -128 :S!
Great work on finding this one, I have implemented the fix :).
-
Cool to hear. :D On a side note I have a window routine done. It displays 5 rectangles then pastes the 4 rounded corner sprites over it, so it looks like the Final Fantasy boxes.
-
Nice!
Im working on the example BASIC RPG which helps me come up with functions to speed up gameplay.
One that im going to add is: DRAWTILEBGLIST, which will draw tiles as per a list of X/Y values. This will save time when drawing the backgrounds of onscreen sprites.
Screenie, note that the sprites dont flicker in the emu or on calc:
(http://img.ourl.ca/ademo.gif)
-
That is looking pretty awesome! Great job!
-
Those graphics look very nice tr1p1ea. :D Also how do you do the animated water and flowers? Do you use two completely different tileset or just two different map data?
Also DRAWTILEBGLIST might be handy if I ever revive Super Sonic Ball CSE.
-
The animated tiles are a bi-product of having 2 GRAM areas, I take advantage of the 'replacetile' function so that i only need 1 tileset. Basically i do:
DRAWMAP GRAM1
REPLACE ANIMATED TILES
DRAWMAP GRAM2
RESTORE ANIMATED TILES
Then everytime you do an UPDATELCD, you get animated tiles!
The trick is to come up with animations that work with only 2 frames.
-
Ah right I forgot about the Replace tile command. Thanks for the explanation.
That reminds me, I wonder when did Kerm plan a new release of DCSE8? I might try to continue working on Reuben again at one point, but if I know there are still months to go before the release with new xLIBC commands, I'll just proceed with the game but use temporary placeholders for the level 2 animations. I still need to redo all my maps, though, since I moved many tiles around.
-
Well i think the next testing phase for DCSE8 is early June, and new xLIBC commands will be included.
-
Ok cool to hear :D
-
I have done a little more work on the enemy sprites, it can be quite challenging to get something recognizable at 8x8 and with only 2 frames for animation.
(http://img.ourl.ca/xlibc2.gif)
See if you can recognise: snail, beetle, jellyfish, scorpion, rat, cat, snake, crab, bat, spider & butterfly.
Still thinking up ideas to make the speed at little better (this is BASIC though).
-
I can recognize them all :D The cat and rat are the hardest but it is possible.
-
I can't really recognize 'em :/
But it is still looking awesome :P
-
Same as aeTIos, I recognized them all :D
I just had a hard time seeing them all as their apparitions seem to be random so I was like "where's that rat ?" :P
-
I recognize some but not all. Some seems like 8x8 renditions of Zelda tiles, while others seems like colored versions of the original xLIB demo in 2005.
That said, I guess this RPG release, if it comes out before Reuben CSE, will mark the official switch back to the original Reuben CSE title idea rather than the other idea I had, since the other idea I had for a title was in reference to how it would have been the first ever 84+CSE RPG :P
-
Given the high resolution, I'd like to see 16*16 tiles and sprite on this calculator. In Illusiat Axe, I work with 6*8 on the map, 8*8 floor and 16*16 character/monster in the battle engine. But that's on a much smaller resolution so they are actually bigger.
-
Maybe xLIB could have an option for 16x16 tiles? (although vertical resolution would be a problem since the 8th row of tiles wouldn't fit completely)
-
Brief explanation of sprite collision function, it tests for collisions between rectangular coordinates so if you have say a sprite that is:
X = 10
Y = 10
W = 8
H = 8
And you wanted to test if this 'rectangle' overlaps with an enemy sprite at:
X = 15
Y = 15
W = 8
H = 8
Like so:
(http://img.ourl.ca/c1.png)
Then you can use the function to check:
real(4,6,1,10,10,8,8,15,15,8,8
In which case they do collide so the result will be a list:
{1,1,0
{1 = collision found
1 = number of collisions found
0 = index of collision passed with real( statement
And since there was only 1 set of coordinates passed the first index that collided is 0 (the red square).
Another case:
Rectangles at:
X = 10
Y = 10
W = 8
H = 8
Tested against others where:
X = 15
Y = 15
W = 8
H = 8
X = 48
Y = 32
W = 16
H = 16
X = 8
Y = 0
W = 64
H = 16
Like so:
(http://img.ourl.ca/c2-1.png)
The call would be: real(4,6,3,10,10,8,8,15,15,8,8,48,32,16,16,8,0,64,16
And the result would be:
{1,2,0,2
{1 = collision found (would be 0 if no collisions occured)
2 = number of collisions found (green and red)
0 = collision with index 0 (red)
2 = collision with index 2 (green)
Index 1 is the orange square for which there was no collision.
-
Interesting, but I thought there were already similar collision routines available? Or is it just because they were bundled with getkey and this one is for people who want to getkey separately? This might be handy, though. I like collision boxes since this can make it much easier for games using larger sprites such as bosses or 16x16 games.
-
There is already sprite<->tilemap collisions but no facility for sprite<->sprite collisions.
-
Oh right I see now. Thanks for the clarification :)
EDIT: Does the new xLIBC allow people to use Output() when using xLIBC drawing commands? Right now, you have to use real(0,1,0,1) before using Output, else it's screwed up, but then you are stuck with the gray bar at the screen top. Hexatron is doing a Celtic remake of Illusiat 11, but would like to get rid of the gray bar:
(http://img.ourl.ca/illusiat11mockup-3.png) (http://img.ourl.ca/illusiat11mockup-2.png)
-
Oh right I see now. Thanks for the clarification :)
EDIT: Does the new xLIBC allow people to use Output() when using xLIBC drawing commands? Right now, you have to use real(0,1,0,1) before using Output, else it's screwed up, but then you are stuck with the gray bar at the screen top. Hexatron is doing a Celtic remake of Illusiat 11, but would like to get rid of the gray bar:
(http://img.ourl.ca/illusiat11mockup-3.png) (http://img.ourl.ca/illusiat11mockup-2.png)
No longer necessary (I did it in ASM), but it still would be a nice feature.
-
Why not just use xLib's draw string method?
-
He wanted to stick to the TI-OS ASCII characters so that he doesn't have to modify the entire game with many real( commands. The goal was to keep the game as it is, but still apply some minor updates such as color additions, perhaps an HUD or a logo and get rid of the surrounding gray/white.
-
Yeah. It was more of a port than a total remake.
-
Well you can still draw to both sides of GRAM without setting half-res mode, you just need to do it in 2 calls.
-
True but that's not really the issue: The issue was that every xLIBC drawing command (DrawShape, DrawSprite, DrawMap, DrawString and filling the screen) screws up the Output command no matter if you are in full or half res. TO fix Output you need to run real(0,1,0,1, which has the adverse effect or redrawing that ugly gray bar at the top of the screen.
Basically, Hexatron absolutely wants to use Output() without being stuck with the gray bar.
-
Good news, i fixed the Output( bug! Now xLIBC commands play nicely with the TIOS :).
Also i discovered that returning values into a List in Ans is SLOW. So slow that it halved the fps of the xLIBC DEMO :S. But the workaround is that I now create a user-defined list call "XL" that holds all the arguments needed. This is only for the Sprite Collision routines. But I probably should port it over to the getKey->List routine as well.
-
Awesome to hear :D. When this come out, I should tell Hexatron that he no longer needs his ASM routine to turn the screen black :P. Hopefully I can also find time to resume Reuben (thankfully the menu shouldn't be that hard now that I have a menu box routine done.
-
Question: Does the new xLIBC version work with very large string files? (such as 60 KB large)
Also, is there a command to store a string to Str0-Str9 without copying it to Ans first? For example, something like real(6,3,"HELLO WORLD, MY NAME IS "+Sub("JAMESDAVIDMATT JOEY ",L1(25)*5+1,5)+"!",6) that would store to Str6 and work with strings of any size (or at least up to 8 KB or so).
The current issue is that when we need to copy a map to a string for use with the DrawMap command, it takes a crapload of RAM (enough RAM for the program containing the string data, plus twice or three times the RAM required to store the string).
-
If you want to free up RAM from using the string, just store the data to a string and put a :0 after it, so it resets ANS to 0.
For example:
returns 0 as Ans.
-
Yeah this is not for displaying strings anyway, more for map data storage in my case (strings up to 7 or 9 KB in size)
-
Yeah there isnt going to be anything here that will stop the TIOS from using Ans when assigning data to a string sadly. Though I will think about possible ways to do it - just with the timeline for 8.1 im not sure that anything will make it for this version.
EDIT This is what has been added/modified so far for DCSE8.1:
SETUPCOLOURMODE: (TIOS VALUES): -------------------------------
real(0,3,VALUE
VALUE defines action to take:
0 = FULL colour
1 = 8COLOUR
2 = COLOURINVERT
3 = COLOURINVERTOFF (restore to normal)
4 = FILLSCREEN
5 = SETCOLOUROFFSET (DCSE8.1)
To invert the colours on the screen you would do:
real(0,3,2
To restore the colours back to normal you can do:
real(0,3,2
This is because inverting something twice will restore it back to nomral.
To restore the colours back to normal when you dont know the previous state of the screen:
real(0,3,3
To FILL the screen (active GRAM side only) with a colour from the standard xLIB 256 colour palette:
real(0,3,4,COLOUR,UPDATELCD
To set the COLOUR_OFFSET value which is used by sprite and shape routines (note that VALUE is between 0-255)
This will change the colour values per pixel of sprites as they are drawn to the LCD. It can be used for
special effects (magic animations for example):
real(0,3,5,VALUE
=================================================================================================================
GETKEY UP/DOWN/LEFT/RIGHT CHECKTILE LIST (DCSE8.1):
---------------------------------------------------
real(2,5,USERVAR_X,USERVAR_Y,VALUE_X,VALUE_Y,USERVAR_MAPWIDTH,COLLISIONTILE,MAPSTRING,X0,Y0,X1,Y1
USERVAR_MAPWIDTH = width of tilemap in tiles (uservar 0-255)
COLLISIONTILE = upper limit of walkable tiles (any tile less than this will be walkable)
MAPSTRING = string variable holding tilemap data (0-10)
X0 = left x coordinate of collision box
Y0 = top y coordinate of collision box
X1 = right x coordinate of collision box
Y1 = bottom y coordinate of collision box
This function is the same as the above however it will return information regarding any keypresses and
any collided tiles in a 'real list' contained in with the format:
{KEY_PRESS, NUM_COLLIDED_TILES, COLLIDED_TILES_LIST} where:
KEY_PRESS = -1,0,1,2,3 = NOARROW,UP,DOWN,LEFT,RIGHT
NUM_COLLIDED_TILES = number of tiles collided against given the arguments in the call
COLLIDED_TILES_LIST = list of tiles collided against given the arguments in the call
GETKEY UP/DOWN/LEFT/RIGHT/DIAGONAL CHECKTILE LIST (DCSE8.1):
------------------------------------------------------------
real(2,6,USERVAR_X,USERVAR_Y,VALUE_X,VALUE_Y,USERVAR_MAPWIDTH,COLLISIONTILE,MAPSTRING,X0,Y0,X1,Y1
refer to the above function, adds diagonal keypresses as well
=================================================================================================================
DRAWSPRITECHECKCOLLISIONA (TIOS VALUES, DCSE8.1):
-------------------------------------------------
real(4,6,COUNT,X,Y,W,H,CX0,CY0,CW0,CH0....CXn,CYn,CWn,CHn
COUNT = number of coordinates to check against
X = master X to test list of coordinates against
Y = master Y to test list of coordinates against
W = master W to test list of coordinates against
H = master H to test list of coordinates against
CX0 = first X to test against master X
CY0 = first Y to test against master Y
CW0 = first W to test against master W
CH0 = first H to test against master H
CXn = nth X to test against master X
CYn = nth Y to test against master Y
CWn = nth W to test against master W
CHn = nth H to test against master H
nth should be equal to COUNT
This function will test the rectangular coordinates specified by the 'master X,Y,W,H' against each iteration of rectangular
coordinates from CX0,CY0,CW0,CH0 to CXn,CYn,CWn,CHn and will return
0 or 1 in Ans where 0 = no collision between the 'master set' and the list and 1 = a collision with at least 1 set isfound
A list of collided coordinate indexes in the user-defined 'real list' "XL" in the format:
{TOTAL_COORDS_COLLIDED,INDEX0...INDEXn} Where:
TOTAL_COORDS_COLLIDED = total number of rectangular indexes in the call that collide with the 'master set'
INDEX0 = first index where 0 = the rectangular coordinates [CX0,CY0,CW0,CH0] and n would equal the [CX0,CY0,CW0,CH0]
Note that user-define list "XL" is overwritten if it already exists
For example
Rectangles at:
X = 10
Y = 10
W = 8
H = 8
Tested against others where:
X = 15
Y = 15
W = 8
H = 8
X = 48
Y = 32
W = 16
H = 16
X = 8
Y = 0
W = 64
H = 16
Like so:
The call would be: real(4,6,3,10,10,8,8,15,15,8,8,48,32,16,16,8,0,64,16
And the result would be:
Ans = 1
XL = {1,2,0,2
Ans=1 = collision found
{1 = collision found (would be 0 if no collisions occured)
2 = number of collisions found
0 = collision with index 0
2 = collision with index 2
Index 1 is the square for which there was no collision.
You can check if there is a collision by using:
If Ans
If LXL(1)
Or by a similar method.
DRAWSPRITECHECKCOLLISIONB (USERVAR VALUES, DCSE8.1):
----------------------------------------------------
real(4,7,COUNT,X,Y,W,H,CX0,CY0,CW0,CH0....CXn,CYn,CWn,CHn
COUNT = number of coordinates to check against
X = master X to test list of coordinates against (uservar)
Y = master Y to test list of coordinates against (uservar)
W = master W to test list of coordinates against (uservar)
H = master H to test list of coordinates against (uservar)
CX0 = first X to test against master X (uservar)
CY0 = first Y to test against master Y (uservar)
CW0 = first W to test against master W (uservar)
CH0 = first H to test against master H (uservar)
CXn = nth X to test against master X (uservar)
CYn = nth Y to test against master Y (uservar)
CWn = nth W to test against master W (uservar)
CHn = nth H to test against master H (uservar)
This function is the same as above however it takes references to USERVAR values as opposed to values directly.
DRAWSPRITESEQUENTIALLISTA (TIOS VALUES, DCSE8.1):
-------------------------------------------------
real(4,8,X,Y,WIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,PICINDEXSTART,PICINDEX0
X = x value
Y = y value
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
PICINDEXSTART = pic index to start drawing from (in following list)
PICINDEX0 = pic index in sprite data sheet
This function will draw a sprite that of any size as per the same fashion as DRAWSPRITEA with the only difference
being that you DONT need to specify each PICINDEX for a largesprite, rather you only need to specify the FIRST PICINDEX.
This means that your 8x8 sprite chunks will need to follow each other in your TILEPIC in SEQUENTIAL ORDER. The makeup of
a large sprite is the same:
16x16 sprite list layout:
---------
| 1 | 3 |
---------
| 2 | 4 |
---------
24x24 sprite list layout:
-------------
| 1 | 4 | 7 |
-------------
| 2 | 5 | 8 |
-------------
| 3 | 6 | 9 |
-------------
For both of the above you only need to specifiy the PICINDEX '1' (along with appropriate WIDTH/HEIGHT ETC) to draw.
The advantage is that you save space in BASIC code, speed of execution and you can maximise the space in your TILEPICS.
The drawback is that the layout of sprites requires more work when creating your TILEPICS.
You can use the PICINDEXSTART argument to have largesprite 'frames' as each PICINDEX you supply will be the STARTING INDEX
for each frame so having:
real(4,8,10,10,2,2,0,0,248,1,0,10,20
Will draw a 16x16 sprite with the 4 '8x8 chunks' starting at INDEX 10 (10,11,12,13). If you change the PICINDEXSTART
argument to 1 then the 16x16 sprite will be made up of the 4 '8x8 chunks' starting at INDEX 20 (20,21,22,23).
DRAWSPRITESEQUENTIALLISTB (USERVAR VALUES, DCSE8.1):
----------------------------------------------------
real(4,9,USERVAR_X,USERVAR_Y,WIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,PICINDEXSTART,PICINDEX0
X = x value (uservar 0-255)
Y = y value (uservar 0-255)
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
PICINDEXSTART = pic index to start drawing from (in following list)
PICINDEX0 = pic index in sprite data sheet
This function is the same as above however it takes references to internal USERVARS as opposed to values directly
DRAWSPRITETILEBGLISTA (TIOS VALUES, DCSE8.1):
---------------------------------------------
real(4,10,LISTCOUNT,LISTWIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,MAPWIDTH,MAPSTRING,X0,Y0...Xn,Yn
LISTCOUNT = number of tiles in list
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
MAPWIDTH = width of tilemap
MAPSTRING = string variable holding tilemap data (0-10)
X0 = first X value to draw tile at
Y0 = first Y value to draw tile at
Xn = last X value to draw tile at
Yn = last Y value to draw tile at
This function will draw the tiles for width*height at the sprite coordinate listed from X0,Y0 to Xn,Yn. The resultant tiles
will be aligned to the map (it will only draw at intevals of 8-pixels). This is useful for restoring a tilemap background
that has been overwritten by a list of sprites. As mentioned this function is the same as DRAWSPRITETILEBG just witha list.
DRAWSPRITETILEBGLISTB (USERVARS VALUES, DCSE8.1):
-------------------------------------------------
real(4,10,LISTCOUNT,LISTWIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,MAPWIDTH,MAPSTRING,X0,Y0...Xn,Yn
LISTCOUNT = number of tiles in list
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
MAPWIDTH = width of tilemap (uservar 0-255)
MAPSTRING = string variable holding tilemap data (0-10)
X0 = first X value to draw tile at (uservar 0-255)
Y0 = first Y value to draw tile at (uservar 0-255)
Xn = last X value to draw tile at (uservar 0-255)
Yn = last Y value to draw tile at (uservar 0-255)
This function is the same as above how it takes references to internal USERVARS as opposed to direct values in the call
=================================================================================================================
DISPLAYBGPIC32 (TIOS VALUES, DCSE8.1):
--------------------------------------
:"APPVARNAME
real(5,6,UPDATELCD
UPDATELCD = 0/1 to update LCD after drawing
This function will display a custom 32 colour 160x120 image (scaled to fullscreen) appvar (name stored as a string in ANS).
To display a bgpic named "BGTEST":
:"BG32TEST
:real(5,6,1
=================================================================================================================
FILLRORTATECOLOURSRECTANGLE (TIOS VALUES, DCSE8.1):
---------------------------------------------------
real(7,13,X0,Y0,WIDTH,HEIGHT,UPDATELCD
X0 = left x value
Y0 = top y value
WIDTH = width of rectangle
HEIGHT = height of rectangle
UPDATELCD = 0/1 to update LCD after drawing
This function draws a filled rectangle starting at X0,Y0 for WIDTH,HEIGHT. Any pixles that it overlaps
will be rotated according to the value of COLOUR_OFFSET (see SETUPCOLORMODE in the SETUP section)
-
I can't wait to give it a try :D
-
(http://img.ourl.ca/rainbowtest.gif)
The new rectangle color rotating tools are fun :D
-
Yay hue shift ! :D This looks pretty cool.