Please note that the RC2 version of DrawSpriteTileBGA/B is bugged. This has been fixed however it is a bit annoying for tilemap testing since that function can be useful.
Possible bug with the uservars commands:

real(1,2 and real(1,3 doesn't do anything and displays the wrong value . 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.

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:

Code:
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:

Code:
real(1,0,real(1,2,127,2
It'll be cool when the official version is released! So Kerm, we'll get a surprise mouse at the very end, right? I'll take this moment to respond to the naysayers: NO! The mouse is not the most efficient way to navigate DCS. But it is nice! Besides, what does the wiki say?
Quote:
Doors CS 7.2
-Extremely user-friendly, with a mouse and tons of keyboard shortcuts
Doors CSE 8.0
-nothing, of course it is not released yet! But I ask, What will it say? I bet something along the lines of (based on the above statement):
-Extremely user-unfriendly, without a mouse, only the keyboard shortcuts


I'm just pointing out - the mouse was a much extolled feature last time, and, NO, it's not there to make DCS faster to use - just more familiar and pleasant.
Caleb, while I agree that I liked the mouse, you need to step back for a second and take a look at it from his perspective.

Kerm received a never ending supply of "Why a mouse on a calculator? This is a bad UI, I just want to select like MirageOS" comments that he was just super tired of it (And to be honest, a lot of us got tired of people complaining about such a nifty feature) that I don't hold it against Kerm not to include it. Yes, I'd love to see it, but I understand why it's not going to be included.
It would be cool if the background text function could take the standard basic colors, that way programmers who require fewer colors can save some space.
so with the current build that you sent me the background color stays grey no madder what i change the background to in the graph.
Roxas240 wrote:
so with the current build that you sent me the background color stays grey no madder what i change the background to in the graph.
I can't replicate this. The following BASIC code works fine from the homescreen and DCS desktop:
Code:
:BackgroundOn RED
:DispGraph
:Pause


merthsoft wrote:
It would be cool if the background text function could take the standard basic colors, that way programmers who require fewer colors can save some space.
Ask and you shall receive:
Roxas240 wrote:
so with the current build that you sent me the background color stays grey no madder what i change the background to in the graph.


Umm that's EXTREMELY simple (not a bug at all)
Just call

Code:
GridOff
KermMartian wrote:
Wonderful! Thanks! Now, can I get my hands on it Smile
merthsoft wrote:
Wonderful! Thanks! Now, can I get my hands on it Smile
We're shooting for tomorrow for the 8.0.0 release, but I'd be more than happy to throw you the current build if you want to work with it today and tell me if you find any det(12) bugs. Wink
I think I have squashed all bugs that I know of, I'll send you the latest in a few gours! If no one has any more.
tr1p1ea wrote:
I think I have squashed all bugs that I know of, I'll send you the latest in a few gours! If no one has any more.
I hope I receive that code soon. Wink I'm very anxious to get Doors CSE 8.0 out today. Very Happy The only thing I'm struggling with is an APD bug that I can't replicate, and I think I've added everything I can to make sure APD is properly set up when Doors CSE quits.
KermMartian wrote:
So I created a bit of a fonthook at the expense of about 200 bytes on page 1 that fills in the two pixels below homescreen characters with the background color when DCSE's color-text mode is enabled, like so:



I have two questions for you guys:
1) Should I bother trying to find a safe way to back up and restore any existing font hooks?
2) Should I insist people release their DCSE8 ASM programs unlocked, so that users can see the OpenLib(DoorsCSE) header? With them locked, that header is sort of useless as a hint to download the shell.


Question about this fonthook: Does it eliminate the possibility of any custom font support via DCSE or a third-party app? Because Cumred made a custom font for the CSE (although only the built-in font is supported) and while it doesn't appear to break Doors CSE, the custom fonts will not display while a BASIC program is running if Doors CSE is enabled.



A mockup of what could be possible with custom fonts combined with det(12 :

DJ_O wrote:
Question about this fonthook: Does it eliminate the possibility of any custom font support via DCSE or a third-party app? Because Cumred made a custom font for the CSE (although only the built-in font is supported) and while it doesn't appear to break Doors CSE, the custom fonts will not display while a BASIC program is running if Doors CSE is enabled.
Unfortunately, for speed reasons, I had to disable chaining of font hooks with this special font hook. If I had chaining, then every character would incur an AppVar lookup, which I find pretty unacceptable speed-wise. Therefore, once the homescreen color text hook has been activated by calling det(12) once, font hooks will not work.

Quote:
A mockup of what could be possible with custom fonts combined with det(12 :

Very cool! I wish that was possible at a good speed on the CSE.
It might be nice to make that optional, or somehow support a custom font as well. For some people, it might be worth the performance hit, though I certainly agree that doing it for everything may not be worth it.
Yeah an option would be nice, eg via det(12,colorstuff,colorstuff,colorstuff,colorstuff,customfontenabled syntax, where customfontenabled would have fonts disabled by default if not specified or if set to zero. That's, of course, unless adding such option actually slowed things down by itself or if you are out of space in the DCSE application.

Would the speed loss be the same if you used Omnicalc 8xp font format instead? That would cause serious issues about RAM space, though, since the CSE has 3 KB less than the SE.

For a game like First Fantasy I think the speed loss would be fine, since the speed is already quite high (some stuff even had to be slowed down), but of course it depends how bad it is. If it's like three times slower for everything, then maybe not.

EDIT: Apparently Cumred stores his hook in a random RAM location (EDIT 2: He says he uses 5 bytes at 9B90h somewhere near basic_prog and pc_end or something). Not sure if that would make any difference in speed, though.
KermMartian wrote:
DJ_O wrote:
Question about this fonthook: Does it eliminate the possibility of any custom font support via DCSE or a third-party app? Because Cumred made a custom font for the CSE (although only the built-in font is supported) and while it doesn't appear to break Doors CSE, the custom fonts will not display while a BASIC program is running if Doors CSE is enabled.
Unfortunately, for speed reasons, I had to disable chaining of font hooks with this special font hook. If I had chaining, then every character would incur an AppVar lookup, which I find pretty unacceptable speed-wise. Therefore, once the homescreen color text hook has been activated by calling det(12) once, font hooks will not work.
I did some experimentation with OS quirks I discovered during my work with Graph3DC, namely that textInverse causes the OS to draw taller backgrounds behind characters. Unfortunately, this taller (18-pixel) background is the same as when textEraseBelow,(iy+textFlags) is set, and which I was already using in Doors CSE. I was hoping I'd be able to coax the OS to draw a tall enough background that the fontHook would not be necessary to compensate for the too-short normal (17-pixel) background, but alas, I can't get it all the way to 20 pixels, and I explored the internals of the OS _PutC call thoroughly to determine this. The only option would be to chain the fontHook in BASIC programs, and I'm not ready to commit to using a possibly volatile RAM location for that yet.
  
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
Page 4 of 4
» All times are UTC - 5 Hours
 
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

 

Advertisement