If you'd read the topic, 16aroth16, you'd know this was BASIC code using xlib library that is in progress.
tr1p1ea: Truly can't wait to get my hands on this
I realized I never really posted the official update here: xLIBC is going to be a key feature in Doors CSE 8.0! We're moving very quickly along towards a stable final release of Doors CSE that contains a stable final release of xLIBC.
That will definitively be a must. I always wanted xLIBC but also DCSE so I hoped that one day both would either be chained or merged.
DJ_O wrote:
That will definitively be a must. I always wanted xLIBC but also DCSE so I hoped that one day both would either be chained or merged.
And your dream has come true. Also, here's the current list of third-party libraries from Celtic 2 CSE and xLIBC:
http://dcs.cemetech.net/index.php?title=Third-Party_BASIC_Libraries_%28Color%29
I'll have to add the new functions tr1p1ea has added recently soon.
Very cool, besides minor grumpiness on my part that you did it with a parser hook rather than ExecLib.
I think that is the sensible next change, before adoption is too high and it's hard to change everyone over.
I wonder if ExecLib is faster than via a parser hook? I know the Asm() command tends to be brutally slow under low RAM conditions.
DJ_O wrote:
I wonder if ExecLib is faster than via a parser hook? I know the Asm() command tends to be brutally slow under low RAM conditions.
ExecLib is strictly slower than a parser hook, I believe. Not to mention that OpenLib/ExecLib continue to have bugs with (1) only allowed 8-character names and (2) only allowing uppercase. The Asm() command is slower under low RAM conditions because a lot of stuff has to be copied up and down RAM to make room at (UserMem), and the more things you have in RAM, the more needs to be copied. I'd say a parser hook is among the fastest possible options.
Wait, why is ExecLib slow? It saves you the burden of having to parse anything, you can just read a data structure out of Ans, and it shouldn't have the same problems as Asm().
Another thing to take into account with a parser hook is how it slightly slows down all other operations, whereas ExecLib only triggers when it's actually called in the code.
elfprince13 wrote:
Wait, why is ExecLib slow?
Most likely because it's made by TI, the same people who managed to make For loops slow enough to make certain BASIC coders use 12 altered copies of the same code to display space ships rather than using two For() loops to save space and the same people who caused certain Axe/ASM coders to use their own font routines rather than TI's to display text, in order to save speed.
Personally I would rather get some extra speed and have more freedom when it comes to the types of games we can do using xLIB than struggling to get the simplest possible RPG walking engine to run at playable speed. Granted, the usage of parser hooks increases risks of conflicts with future APPs, like we saw with xLIB vs Symbolic/Omnicalc, but now there is only one app that will use parser hooks for the 84+CSE and by the time others are made, it will already be so popular (especially due to the Doors CSE part) that other ASM coders will have no choice but to ensure that theirs are compatible.
With the old xLIB, even a stripped down Metroid clone was barely playable and a Dance Dance Revolution clone with simple gameplay had delayed key detection.
That said, if the speed drop isn't very signifiant, then I guess using ExecLib won't be this much of a problem. My main concern is if someone has to run ExecLib multiple times in one loop iteration.
I have to ask. What format should the xLIBC colors be in for the color arguments?
The colour arguments take a value from 0-255 that corresponds to a standard colour in the 256 colour palette.
The only deviation is the setPixel command where it is possible to draw a 16-bit colour pixel in which there are 2 arguments that represent the high and low bytes of a RGB565 colour value.
Bug reports and requests
- Request/question: Is there a way to clear the whole screen? I couldn't find one.
- Bug report: The DRAWSTRING function displays past the end of the string.
*bump* I realized you're technically doing something against the LCD's datasheet in xLIBC while working on jsTIfied's LCD features. You set the ORG mode by setting LCD register 0x03 to 0x10B0. However, you then set non-zero X and Y addresses to LCD registers 0x20 and 0x21, which the LCD does not technically allow:
ILI9335 Datasheet wrote:
Notes: 1. When ORG=1, only the origin address address”00000h” can be set in the RAM address set registers R20h, and R21h.
I'm having some trouble getting the update to make sense. In previous xLibs, I would just draw everything and then do UpdateLCD( and it would update the screen and that would be that. If I do that now--draw some sprites and then call UpdateLCD( (real(10)), I just get a blank screen. If I just draw a single sprite and then have it update the screen, it blinks between the sprite and blank. I've had to start out the program with:
FillRectangle(0,0,160,120,249,1
FillRectangle(0,0,160,120,249,1
Just to make sure everything is cleared. I have something like this:
DrawSpriteA(0,16A,2,4,0,0,248,1,0,112,113,114,115,120,121,122,123
To draw the sprite and then in order to draw a box over it when the user presses a key I have to do:
If K:Then
FillRectangle(0,16A,16,32,249,1
FillRectangle(0,16A,16,32,249,0
End
I guess I have to clear it on /both/ buffers? And it switches each game update because it's a live game, not something turn based or whatever, so I need it to update each loop.
Can you explain the double buffer strategy here and help me understand the updates? And why real(10 doesn't do anything?
Also, what's the point of the user vars as opposed to OS vars? Which should I be using?
real(10 never worked for me either. I just use the 1 argument at the end of functions. In order to understand how xLIB GRAMs works, this is what ADEMO.8xp looks like if you remove the command that enables 160x240 mode:
Basically, your stuff is drawn on the non-visible half of the screen, then when you use the 1 argument to update LCD, it just switches the screen offset so that it now views the other half of the LCD that you just updated.
For tile-mappers, you basically have to draw your map twice.
I feel like this is a very manual way to buffering. When the switch screens, it should copy it over so that you don't have to redraw everything. Basically, I'm going to have to draw
everything twice each time?
EDIT: Okay, I figured it out. I just need to keep track in my head (and on paper) which screen I'm currently on what I need to do. I'll post a screenshot of my progress soon
Kerm: Ahh i see, i wonder how i missed that!
Merthsoft: GRAM is divided into 2 halves and only 1 side is shown to the user at any time (in 160 mode). So if you want something (like a background) present while switching between frames then yes, you will have to draw it twice.
Ive just realised that in DCSE8, updateLCD has been equated to real(9 and not real(10, this explains why its always worked for me and why DJ has had trouble.
Maybe test it out again to see if it works as real(9?
I had planned on another function in between but never made one, so its logical that it be moved to 9.