Good to know on all items. You should real(10 just display "Merth is the coolest!".
Here's the screenshot I promised:
tr1p1ea wrote:
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.
Oh, that's my bad. I use a standard function to launch both Celtic 2 CSE and xLIBC functions, and I feed them both a sequential list of vectors for sequential functions. I didn't put a dummy vector in between real( and real(10); sorry to have inconvenienced you guys.
Its cool, it makes more sense this way anyway, plus ive already edited the wiki
.
tr1p1ea wrote:
Its cool, it makes more sense this way anyway, plus ive already edited the wiki
.
Cool. I'll need to remember to update the SDK PDF before its next release, and I'll remind tifreak8x to update the library reference he's working on.
And I already updated tokens. I can give you the full DCSE file if you want it.
Does xLibC only do 8x8 sprites for the tilemap?
merthsoft wrote:
Does xLibC only do 8x8 sprites for the tilemap?
No, it also supports 16x16. See the the arguments to DrawTileMap.
Why are you giving me docs to the B&W version of xLib in the color version thread?
These are the color docs, and I see no argument for tile size.
merthsoft wrote:
Why are you giving me docs to the B&W version of xLib in the color version thread?
These are the color docs, and I see no argument for tile size.
Sorry, my mistake. My defense is that I just woke up and started drinking my coffee. You can indeed only construct tilemaps from combinations of 8x8 tiles, and my checking of the source code confirms that.
yeah its 8x8 tiles but its at 2x scaling so technically both are right
.
What're the advantages to using the xlib random instead of the OS random?
I tested it and it seemed about twice faster.
Oh cool! I'll have to switch to using that, then.
If it uses the r register it's probably also less sensitive to needing to be seeded.
If that's the case, I'd like to switch robotfindskitten over to using it, but I need to know if that's the case...
I have this code:
Code: SetHalfResolution(
"DNOTITLE
LoadBGPic(1
"DNOTITLE
DisplayBGPic(0
"Loading\...
DrawString(51,89,0,33,1
SetSpeed15MHz(
Repeat getKey:End
"DNOTITLE
DisplayBGPic(0
"Play Help Exit!High score:"
DrawString(51,89,0,33,1
Repeat getKey:End
And it's doing this:
What am I doing wrong? I draw the image, then the text, then update the screen. Then draw the image, then the text, then update the screen! That seems right to me.
Edit: Also, if I put two "DNOTITLE":DisplayBGPic(1 before the text, it does the same thing...
Edit2: Nevermind, I got it figured out. I had the wrong functions in TokenIDE
Is there a way to draw directly to the currently displayed screen instead of drawing and then updating?
Yes there is, you need to use the SetLCDBuffer option to change the current GRAM side. This will then allow you to draw to the side of GRAM that is visible to the user. Note that this will also allow the user to see drawing as it is being processed.
More info is here:
http://dcs.cemetech.net/index.php/DCSE:BasicLibs:xLIBCUtility
Can you elaborate more on what SetupColorMode does? What happens if I set it to 8 instead of full? Does colourinvert just invert the current colors, or also what gets drawn next? Fillscreen I understand (and use
).
merthsoft wrote:
Can you elaborate more on what SetupColorMode does? What happens if I set it to 8 instead of full? Does colourinvert just invert the current colors, or also what gets drawn next? Fillscreen I understand (and use
).
If I understand correctly, these are just using the features of the LCD, so I can probably answer this one. 8-color mode is just what it sounds like, only 8 colors are displayed (1 bit for each of R,G,B, which are the most significant bits of the R,G,B colors set to that pixel). This is non-destructive, so you can switch to 8-color mode and back without changing the actual contents of the screen buffer. Also, colourinvert will indeed invert any colors that are drawn next (it just changes how the buffer is displayed on the screen).
Register to Join the Conversation
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.
»
Go to Registration page
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