Hi all, this is my first post.. :ox Since bug-list is suffering nowadays, I repost it here: (and just hope this isn't a faux pas) 1. L-system "Thinking" screen freezes up upon this: (Under W98 it announces a restricted instruction or st. like that) Bug { angle 6 axiom F F=[F+F- F=-F+F] } It's somehow caused by spliting related push-pops into multiple lines. 2. Vertical lines all over the screen, when using mode with color bit depth more than 4 bits (16 colors) on a Chips&Techs card. It supports VESA well enough and my own plotings are clear. None of the textsafe options did help. 3. Therefore while wondering thru video.asm I found some bad things: VESAtruewrite in 24+b/color mode forms B-G-B instead of R-G-B (caused by commenting out some lines, but most of the cards require B-G-R anyway, so that branch is rarely passed thru I guess) VESAtruewrite/read and put/gettruecolor in 24+b/color mode call VESAtrueaddr three times! (While calling it once is enough!) So, I rewrote these, it now does about 150% of job in the same time. But then I realised that development is possibly heading a very different way (no asm), so my last question is, should I send video.asm fixups to someone or instantly throw away? thanx, charlie ______________________________________________________________________ Reklama: Volkswagen nyni nabizi akcni model Golf Edition s klimatizaci v cene 36 900 Kc zdarma. http://ad2.seznam.cz/redir.cgi?instance=28672%26url=http://www.volkswagen.cz...
On Tuesday 25 June 2002 07:42 am, Charlie wrote:
Since bug-list is suffering nowadays, I repost it here: (and just hope this isn't a faux pas)
1. L-system "Thinking" screen freezes up upon this: (Under W98 it announces a restricted instruction or st. like that) Bug { angle 6 axiom F F=[F+F- F=-F+F] } It's somehow caused by spliting related push-pops into multiple lines.
I'll have a look.
2. Vertical lines all over the screen, when using mode with color bit depth more than 4 bits (16 colors) on a Chips&Techs card. It supports VESA well enough and my own plotings are clear. None of the textsafe options did help.
3. Therefore while wondering thru video.asm I found some bad things:
VESAtruewrite in 24+b/color mode forms B-G-B instead of R-G-B (caused by commenting out some lines, but most of the cards require B-G-R anyway, so that branch is rarely passed thru I guess)
VESAtruewrite/read and put/gettruecolor in 24+b/color mode call VESAtrueaddr three times! (While calling it once is enough!)
So, I rewrote these, it now does about 150% of job in the same time. But then I realised that development is possibly heading a very different way (no asm), so my last question is, should I send video.asm fixups to someone or instantly throw away?
PLease send the fuxups to me. We are still patching the DOS code. Thanks for the assistance. Jonathan
On Tuesday 25 June 2002 07:42 am, Charlie wrote:
1. L-system "Thinking" screen freezes up upon this: (Under W98 it announces a restricted instruction or st. like that) Bug { angle 6 axiom F F=[F+F- F=-F+F] } It's somehow caused by spliting related push-pops into multiple lines.
Does this work using the integer math? It does for me, but is it the expected image?
3. Therefore while wondering thru video.asm I found some bad things:
VESAtruewrite in 24+b/color mode forms B-G-B instead of R-G-B (caused by commenting out some lines, but most of the cards require B-G-R anyway, so that branch is rarely passed thru I guess)
Haven't looked at this yet, but it is a bit messy. I could have easily gotten it incorrect.
VESAtruewrite/read and put/gettruecolor in 24+b/color mode call VESAtrueaddr three times! (While calling it once is enough!)
As I recall, which isn't very good, the problem occurs when the address crosses a segment boundary. If you don't call VESAtrueaddr you'll get bounced out. Jonathan
(ad thinking-freeze) well, Jonathan, try this one: Bug {; an ordinary Koch curve angle 6 axiom F F=F+F-[- F=-]-F+F } starting from order 0 may produce a bad image starting directly at order 2 freezes every comp i've tested (ad VESAtruewrite)
As I recall, which isn't very good, the problem occurs when the address crosses a segment boundary. If you don't call VESAtrueaddr you'll get bounced out.
hey, believe me ^_^ multiplying line count by line size three times a pixel is not quite good idea while you can check the end of a bank yourself by simple inc and switch when necessary not to worry, i'm sending you this soon (i forgot my floppie @ home v_v ) charlie ------- for_joy: jmp for_joy ______________________________________________________________________ Reklama: Co davaji v TV? http://tv.seznam.cz
..based upon a private mail exchange with Jonathan ------------------------------------------------------------------------------
VESA scrolling (fn 6 & 7) But, how to fit it into the current code?
in framain2.c, line about 150, there is view window setup - instead of showing "view window too large" it could first try to set the VESA virtual line by the xdots - then, the sx/yoffs could be used for scrolling unfortunately, these are used almost everywhere so it would be needed to check the dependencies (zoombox, show-palette, evolver, ..) it may be not worth of it, though (i'll take a much closer look) ------------------------------------------------------------------------------
hp-laserjet's HPGL plotter-simulation mode for L-systems Sending data directly to a printer or plotter is like sending data to the video card when you are dealing with Windows/Unix. It probably doesn't work too well. But, then, I wouldn't really know. If you do the work, and it's reasonably clean, I'll put it in.
it's not direct data sending on the hardware level! it's a plain text printing.. does that work under wins/unix? it still/also can be saved to a print-file.. the amount of output data would follow the l-system complexity, not resolution but as l-systems are drawn recursively, it would need to go thru it once more or to flag on print-out-status before the computation ------------------------------------------------------------------------------
push-pop on-different-lines noisy-freezing-bug I'm not that familiar with the l-system code either. I do recognize the recursion, which would imply that at one point in time, the whole string would be in memory. But, only as recursive calls to the resize() routine. I could be wrong. It happens often.
well, i took another look at it: there is a recursive call to the lsysf_findscale, and then to the drawLSysF both of them would cause that freez-up (but it never gets to the second one) to not mess with this code, it could be repaired in readLSystemFile: where instead of simply saving each line as a separate rule with save_rule, it could first check the presence of a rule for the substituted character, and if already loaded, then it would reallocate that rule and combine it with the new line it would complicate the loading an l-system, but it's executed only once and it would have no impact on the recursion (except solving that bug) ------------------------------------------------------------------------------
scrolling after migration (full-screen mode option)? Isn't it still using VESA calls? For Windows and Unix, that's the same as using vga-ports.
i stay silent as i have no experience with programming for Wins nor Unix.. at least, now i understand why there is a 32-bit entry-point for switching video-memmory banks..
Also, one of the things we seem to be running into is newer graphics cards that don't implement the VESA calls. So they will run Windows but makecfg.exe doesn't report any graphics modes available.
i guess people at VESA aren't much pleased with this but they still don't give up.. maybe they should.. ------------------------------------------------------------------------------ but, those cards don't support VESA at all? or do they only show no supported modes? i found out that my stb vel 3d has an end-of-mode-list sign in the middle of it! (goes like this 0x0101, 0x0102, 0x0103, 0xFFFF, 0x0201, 0x0202, 0xFFFF) while the detection algorithm proceeds until it finds 0xFFFF.. from this point of view, it seems useless: - to talk about setting refresh rate by adding a constant to the VESA mode number (well, it's not that simple, it then awaits additional data in a table) - posting values for some VESA modes that are not included in fractint.cfg (intel740 and stb vel 3d, 256-16m: 320x240, 400x300, 512x384, 1152x864, 1600x1200) ------------------------------------------------------------------------------
Charlie, we should probably move this discussion to the fracdev list.
here it is overwhelmed? sorry ;o) charlie ______________________________________________________________________ Reklama: Jake bude pocasi? http://pocasi.seznam.cz
participants (2)
-
Charlie Chernohorsky -
Jonathan Osuch