oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 18, 2005 19:21:19 GMT -5
i think for some users, you may need to register the ocx manually
you can do this by going regsvr32.exe [OCX name] ^ without the brackers [] thinger in command prompt
|
|
|
Post by Tulio Adriano on Jan 25, 2005 12:41:35 GMT -5
Hey, I found something very strange. Run this code, and watch. ON VBLANK GOSUB Timer ENABLE INTERRUPT VBLANK Dim I As Integer While I < 300 I++ Print I Wend While I > 0 I-- Print I Wend Timer: Print "Hey, This is VBlank. Go back now!" Return
Initialy the prints in the Timer code don't work, later they work but then a weird bug occurs...
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 25, 2005 16:41:12 GMT -5
yea, interrupters were a big problem for basiegaxorz. There are many many bugs that i've already fixed for version 0.20 or whatever. i started to fix these errors when i found out everything borke when i was trying interrupters+rasters =P
1) If your routine takes a lot of time to returnback to normal execution, the interrupter will be re-interrupted =P 2) The cursor is pushed and then popped back out of the stack when you return to normal execution 3) The heap randomly messes up. I temporarily fixed this in versions 0.08 and above by relocating the heap 2000 bytes above the original =P. I now fixed it and found the source of the problem in 0.20 (i think this is the bug that plauged your code) 4) Hblank doesn't work x.x 5) some of the graphics routines did not turn interrupters off, so when interrupters ran, the vdp would become instantly corrupted
here's another thought that i should have documented. if i run your code in the new compiler, a vblank will occur immediately (normal), and then some number will pop up. When your display your numbers, eventually the screen will scroll. Screen scrolling is very slow! the vdp is in dma, and is copying the entire screen to a new location. the entire copying process takes up one whole vblank period, and will start to roll over onto the active display period. when in the active display period, its only copying like 5 bytes for every line. When dma is over, you'll be back in the verticle blank, and yet another interrupter will occur, so you will see no numbers after the screen has scrolled. however, if you decrease the number of characters in your string, you should be able to see some numbers appear =)
i might try to use a faster scrolling method, eg: using verticle scrolling to scroll instead of copying characters with dma. this can be a problem for games that use verticle scrolling (not for text)
edit: my bad, your code has a bug in it, when the counter counts up, then counts back down, code still keeps executing. the compiler does not know there's an interrupter routine on the next line, so execution will immediately occure there, and will definitely crash when it returns from nothing =P (stack underflow)
|
|
|
Post by Tulio Adriano on Jan 26, 2005 6:43:57 GMT -5
In fact I was trying to reproduce a problem in my game (linked in the Noise Machine topic).
The game runs ok, but something very strange happens with loops, that once they're in, when I break the loop (meet the condition to exit or forcing with the EXIT LOOP command, both have the same result) something makes it return to the loop again. This is anoying.
Unfortunately that code didn't reproduded what I wanted, but it reproduced the print weird characters bug when the print command comes from the Vblank interrupter.
I hope next version will fix all those bugs...
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 26, 2005 16:07:32 GMT -5
u mean something like this?
i=0 start: while i<100 i++ print i if i=10 then exit while wend print "asff" while i>0 i-- print i if i=2 then exit while wend print "dddggg" goto start
loops have worked fine for me ever since day 1, but if you do find a bug, i'd still really appreciate it =)
|
|
|
Post by Tulio Adriano on Jan 27, 2005 5:58:03 GMT -5
May be this or the normal exit (for meeting the condition of the While/For).
I believe it has something related to the interrupters, but my code is too large for me to modify and try to discover... that's why I am trying to make a small code to reproduce the problem I had...
Maybe it is something related about what you said of the interrupter being re-interrupted. I will need to try to find out!
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jan 27, 2005 12:33:09 GMT -5
yea, if you're while loop is in the interrupter routine, and the loop takes a while to proccess, more likely, it will be re-interrupted again
|
|
|
Post by RedAngel on Feb 3, 2005 13:01:24 GMT -5
Hi, I have seen that setscrollplane, setscrollmode and scroll2 are case sensitive with the parameters (SCROLL_A and not scroll_a) while settextplane and setgfxplane are not. If I understood well the command scroll does a continuos scroll while scroll2 only scrolls once. I was trying to move the first line of a picture to the left, the second to the right and so on. I can do it with scroll (but it scrolls all the time) and scroll2 scrolls everything to same side . Is this correct?
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Feb 3, 2005 19:20:23 GMT -5
the case sensitivity differences between the commands will be fixed the next version, so cases don't matter at all.
i don't really understand your question, but i'll explain everything you need to know about SCROLL and SCROLL2, and that might help ya out:
scroll and scroll2 both take the same parameters, but change the way the screen is scrolled. like, the command SCROLL will scroll your screen/cell/line relative its current scrolled position, meaning if you first scrolled left by 5, then the next command, you scroll right by 2, then your overall picture will be scrolled to the left by 3. Now for SCROLL2, this should scroll the screen, independent of the current scroll position its at. for example: if you do SCROLL2 to the left by 5, and then SCROLL2 to the right by 3, your overall picture will be scrolled to the right by 3, independent of the previous command where you scrolled to the left by 5. also, i think this relates more back to your question, both scroll commands take in a direction, and an optional value determining the quantity of how much you need to scroll (default is 1). there's also a third optional parameter for both SCROLL and SCROLL2, that choses which scroll entry you want to scroll. If you originally chose to scroll the entire screen, then the third parameter must not have a value. If you want to scroll each cell, then the third parameter will determine which cell entry you want to scroll. If you want to scroll the second cell, you would need to specify 1 as the scroll entry. This is the same for scrolling lines, except you cannot scroll line by line going "UP" and "DOWN". If you don't specify a third parameter, it will always be default to 0, regardless of the scrolling mode you chose
|
|
|
Post by RedAngel on Feb 22, 2005 18:28:33 GMT -5
I am still testing the different ways to scroll and I have discovered that plane b lacks of vertical scrolling and I tried to do a horizontal scroll, line by line, moving all the lines the same quantity (it would be a overall horizontal scroll) but the image is not centered, some lines move more than others.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Feb 22, 2005 20:43:43 GMT -5
there could very well be a bug in basiegaxorz that will not make plane b scroll (i thought i tested this too, there may be something in the examples folder that scrolls both planes, but i could be wrong). i dunno whacha mean by "not being centered". i'd use scroll2 to center the entire screen (or center every single line) to 0
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Mar 9, 2005 16:29:49 GMT -5
oh oh oh i found a bug
PRINT 1+780000000
unfortunately, because of the nature of the compiler, i cannot fix this without doing some extensive changes to the expression parser. this bug is only for the PRINT command because the arguments that preceed this command are varient, and the compiler has to decide what data type an argument is. the expression parser bases this decision upon the fisrt entry in that expression, in the above code, this is 1. now that the compiler thinks the number 1 is within integer range, it will set its data type to integer. when it encounters a huge number afterwards, ie 780000000, it is not within integer range, so it gives an error. i cannot let it so it will change the data type to long when 780000000 is encountered because it will mess everything else up, like a%=1+780000000 turning this legal.
to get around this in your programs, you'll need to trick the compiler like doing PRINT 780000000+1
i can change the print command to print only long variables, but long number displaying gets real slow, but i'll try to optimize this. more likely, there'll be a fix so you don't have to resort to PRINT 780000000+1
|
|
|
Post by Tom Maneiro on Mar 14, 2005 18:43:36 GMT -5
Check these codes, both compiles OK
tag: print "foo" gosub tg2 print "Fin." end
tg2: print "Vaca" return this works fine, but this one...
tg2: print "Vaca" return tag: print "foo" gosub tg2 print "Fin." end ...causes an "Illegal instruction" exception. Compiler should check that, and refuse to compile a Return without GoSub
Also, there should be a way to not run a label, but run it when it is called from another code section above, without using Ifs.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Mar 15, 2005 0:25:04 GMT -5
yes, using a return without a gosub command does crash the processor on purpose because it all has to do with speed, and that the gosub/goto/return commands are all straight assembler (ie respectively jsr label, jmp label, rts). what actually happens when you use rts and the stack is at the very top is a stack underflow. i can lower the stack one more level, and when you use a return statement without it's gosub brother, it will actually jump to a routine yelling at ya: stack underflow. will be done the next version i don't really get your drift here . do you mean select case?
|
|
|
Post by miin on Mar 22, 2005 7:18:51 GMT -5
DANG What The HECK IS WRONG WITH THIS DUMB COMPILER!
68k Gives me This Message every Compile\Assemble INTERRUPT 0DH, GENERAL PROTECTION FAULT possible illegal address error code = 0000 eax = 00043E00 esi = 000400C7 flags = 3246 ds = 017F ebx = FACB0005 edi = 000000C0 eip = 0000351D es = 01C7 ecx = 00000000 ebp = 00C09FFF cs = 019F fs = 01AF edx = 00000000 esp = 000000D2 ss = 017F gs = 0000
|
|