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.
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.
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.
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.
*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:
Just to make sure everything is cleared. I have something like this:
To draw the sprite and then in order to draw a box over it when the user presses a key I have to do:
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
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.
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum