parsec Posted February 26, 2011 Share Posted February 26, 2011 I just managed to compile a new XB-game I am writing using Wilhelm's compiler (wohoo!) and am completely stunned. The speed gain in execution is unbelievable. The problem: Game play in the compiled version is exactly as expected, however, my compiled title screen looks nothing like the XB version. Here is a side-by-side comparison: Left screen shows how it is supposed to look. All strings are printed using DISPLAY AT statements. Obviously something is not right here -- not only is the text placement incorrect, the actual screen position values are printed out. Does Wilhem's compiler not support DISPLAY AT correctly? I can't seem to find anything specific about this in the instructions. Here is the code snippet that goes south: 130 CALL SCREEN(11)::DISPLAY AT(3,6):"the adventures of" 135 DISPLAY AT(5,7):"JUNGLE RAJDEEP" :: DISPLAY AT(9,4):"-= star of africa =-" Is there a good (supported) alternative to DISPLAY AT? Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 (edited) Wilhelm's compiler uses DISPLAY like PRINT... It's confusing. I have a workaround though. =) Use PRINT statements instead of DISPLAY statements instead of DISPLAY AT(8,1):"TI-99!!!"; try to use PRINT... the compiled version is so fast, you won't even see the printint of blank lines C$="TI-99!!!" PRINT C$ FOR I=1 TO 7 :: PRINT :: NEXT I This will accomplish the exact same thing. If you STILL (for some reason) see the printing occur and it bothers yuou, precede your Title screen "draw" with the following code... CALL SCREEN(2) :: FOR I=1 TO 16 :: CALL COLOR(I,2,1):: NEXT I THEN, after the print statements, do all your CALL COLORs and CALL SCREEN. This way, you will see EXACTLY what you want to see, regardless. Hope this helps Edited February 26, 2011 by Opry99er Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 (edited) Of course using that method, you'll have to be aware of your graphics... I'm assuming you're not using DISPLAY AT in your game loop, otherwise you would have reported some crazy stuff in gameplay... If you are using CHR$(124), you'll have to find the key shourtcut for that particular ASCII code... it's not a displayable character, if I remember correctly. You could always use a CALL VCHAR/HCHAR for your title graphics... PRINT ALL THE TITLE TEXT CALL HCHAR(5,6,124) that will probably be the easiest method here... Edited February 26, 2011 by Opry99er Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted February 26, 2011 Share Posted February 26, 2011 I just managed to compile a new XB-game I am writing using Wilhelm's compiler (wohoo!) and am completely stunned. The speed gain in execution is unbelievable. The problem: Game play in the compiled version is exactly as expected, however, my compiled title screen looks nothing like the XB version. Here is a side-by-side comparison: Looks like the compiler is honoring DISPLAY in the standard TI BASIC way (like PRINT,) discarding the token for AT, then ignoring the parenthesis tokens to just print the values you have passed to AT(,) followed by your expected text. Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 26, 2011 Share Posted February 26, 2011 Easiest way would to do this with GOSUB... Populate X,Y,T$ and do a loop with CALL HCHAR. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 I'd be happy to mod the title screen for you if you'd like. =) If you wanted to post the code, I'll try several different methods and do a video about it. =) Quote Link to comment Share on other sites More sharing options...
parsec Posted February 26, 2011 Author Share Posted February 26, 2011 Hey all, I appreciate the fast answers and all the useful tips! Got it working by using HCHAR and DATA like this: 130 CALL SCREEN(11)::RESTORE 8800::FOR I=1 TO 17::READ C$::CALL HCHAR(3,I+7,ASC(C$))::NEXT I 135 FOR I=1 TO 14::READ C$::CALL HCHAR(5,I+8,ASC(C$))::NEXT I 137 FOR I=1 TO 20::READ C$::CALL HCHAR(9,I+5,ASC(C$))::NEXT I ... 8800 DATA "t","h","e"," ","a","d","v","e","n","t","u","r","e","s"," ","o","f" 8810 DATA "J","U","N","G","L","E"," ","R","A","J","D","E","E","P" 8820 DATA "-","="," ","s","t","a","r"," ","o","f"," ","a","f","r","i","c","a"," ","=","-" Somewhat slower in plain vanilla XB compared to DISPLAY AT but no noticeable difference when compiled. Works like a charm now, thanks again! Great tool this compiler is, sprites support it should have... Quote Link to comment Share on other sites More sharing options...
parsec Posted February 26, 2011 Author Share Posted February 26, 2011 Hey Owen, no need now but thanks anyway for your offer A suggestion for a video (if you haven't done it already): How to compile a program using the Wilhelm compiler. I know I struggled for several hours to get it working. Basically what I do now is this to develop and test using Classic99 and compile in Win994a For the latter, I set up Win994a with all three disks mounted as follows: 1) Funnelweb 2) My source disk 3) Wilhelm's compiler Then a) In XB: RUN "DSK3.COMPILER" and follow instructions, exit when finished b) In XB: RUN "DSK1.LOAD" to start FW, select Assembler option and follow instructions c) Unmount disk 1 and exit FW. Start XB again d) RUN "DSK3.CLOADER" and follow instructions e) test run my stuff Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 26, 2011 Share Posted February 26, 2011 Great tool this compiler is, sprites support it should have... Hehehe ... Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 That is a good way... I don't use Funnelweb, so my Order of Operations is a bit different. . Works the same, however. I can do it all in Classic99, assembling source in the Ed/Asm environment rather than FW. Glad you have your code running!!! Looking forward to playing your game!!! Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 Hey sometimes--- any chance you could try something out?? Remember that XB window scroll routine you wrote as a tester for Beryl? Basically it was the same as an assembly scroll routine, only using BASIC DATA statements.... It ran quite slowly in XB, but maybe we could write it without DISPLAY AT and compile it. Could be a very neat exercise! Might lead to some interesting software. Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 26, 2011 Share Posted February 26, 2011 (edited) That is a good way... I don't use Funnelweb, so my Order of Operations is a bit different. . Works the same, however. I can do it all in Classic99, assembling source in the Ed/Asm environment rather than FW. Glad you have your code running!!! Looking forward to playing your game!!! Yep. I'm working on fixing up BloxoTIz now. My order of operations: Willsy's compiler in DSK2. My stuff in DSK1. 1. Save my game as DSK1.BLOX/M,MERGE 2. RUN "DSK2.COMPILER" 3. SPECIFY DSK1.BLOX/M, DSK1.BLOX/S, DSK2 (for files) 4. When Done, Flip classic99 to E/A cartridge 5. Assemble (option 2) 6. SPECIFY DSK1.BLOX/S, DSK1.BLOX/O, <nothing>, R 7 RUN "DSK2.CLOADER" 8. SPECIFY DSK1.BLOX/O 9. Save off my compiled game and go play it! Edited February 26, 2011 by unhuman Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 26, 2011 Share Posted February 26, 2011 Excellent instruction set there--- and my exact order as well. Quote Link to comment Share on other sites More sharing options...
parsec Posted February 26, 2011 Author Share Posted February 26, 2011 Great info, have to try that myself. Takes me 6-8 minutes to compile under Win994a, the CPU overdrive should speed things up a bit... Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted February 26, 2011 Share Posted February 26, 2011 Hey all, I appreciate the fast answers and all the useful tips! Got it working by using HCHAR and DATA like this: 8800 DATA "t","h","e"," ","a","d","v","e","n","t","u","r","e","s"," ","o","f" 8810 DATA "J","U","N","G","L","E"," ","R","A","J","D","E","E","P" 8820 DATA "-","="," ","s","t","a","r"," ","o","f"," ","a","f","r","i","c","a"," ","=","-" I do not use quotes in my data statements. They are non-functional unless you have to include commas in the data to be read, take up memory, and are a PITA to type when moving between them and data. Not to mention that accidentally forgetting one can cause all sorts of disaster. Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 26, 2011 Share Posted February 26, 2011 Try using LEN$ and SEG$ to get the length of and pull out individual chars of your string... I'm assuming the compiler supports both of those - and I'm not gonna check - you try! Hey all, I appreciate the fast answers and all the useful tips! Got it working by using HCHAR and DATA like this: 130 CALL SCREEN(11)::RESTORE 8800::FOR I=1 TO 17::READ C$::CALL HCHAR(3,I+7,ASC(C$))::NEXT I 135 FOR I=1 TO 14::READ C$::CALL HCHAR(5,I+8,ASC(C$))::NEXT I 137 FOR I=1 TO 20::READ C$::CALL HCHAR(9,I+5,ASC(C$))::NEXT I ... 8800 DATA "t","h","e"," ","a","d","v","e","n","t","u","r","e","s"," ","o","f" 8810 DATA "J","U","N","G","L","E"," ","R","A","J","D","E","E","P" 8820 DATA "-","="," ","s","t","a","r"," ","o","f"," ","a","f","r","i","c","a"," ","=","-" Somewhat slower in plain vanilla XB compared to DISPLAY AT but no noticeable difference when compiled. Works like a charm now, thanks again! Great tool this compiler is, sprites support it should have... Quote Link to comment Share on other sites More sharing options...
parsec Posted February 27, 2011 Author Share Posted February 27, 2011 (edited) I do not use quotes in my data statements. See, I thought quotes were mandatory for text strings. Learnt something new again. Try using LEN$ and SEG$ I did try, both are supported. So my final version is a one line subroutine... 4100 FOR I=1 TO LEN(OUT$)::CALL HCHAR(Y,X+I-1,ASC(SEG$(OUT$,I,1)))::NEXT I::RETURN ...and to display some text... 150 OUT$="Some text to print"::Y=5:=9::GOSUB 4100 Edited February 27, 2011 by parsec Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 27, 2011 Share Posted February 27, 2011 Awesome... Print is definitely visible while scrolling (it's really fast though) and wouldn't be good enough for something like printing a score in top right corner. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 27, 2011 Share Posted February 27, 2011 Hey sometimes--- any chance you could try something out?? Remember that XB window scroll routine you wrote as a tester for Beryl? Basically it was the same as an assembly scroll routine, only using BASIC DATA statements.... It ran quite slowly in XB, but maybe we could write it without DISPLAY AT and compile it. Could be a very neat exercise! Might lead to some interesting software. Hi Owen Can't actually remember how far we got with that. Wasn't my intent to like let you do the writing, and me then only trying to point a way ? - Anyways, if I understand your idea correctly, you're thinking about doing the window thing with data statements, read looping, and use CALL HCHAR - and yes sure, you could write the first version of Beryl all in Basic using this Wilhelm compiler (unfortunately no sprites, but I think you could live with that). That's actually an excellent exercise (to get the game done in a, for you, flexible way). Also later translating the Basic version to assembler, is an excellent exercise and assembler learning experience too. - I enjoy both designing and writing assembler almost simultaneously, but often there's too much time spent going forth and back. Designing everything to a certain degree of detail, and then start programming is actually a much a faster overall approach. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.