In this function, there are two arrays that are carved out of extraseg: same and colour. What are the maximum indices into these arrays? The same[] array appears to be indexed from 0 to xdots. However, when colour is carved out of extraseg after same, it is done with this code: same = (int far *)MK_FP(extraseg,0); colour = &same[ydots]; This seems to carve out an array for same[] that is ydots long. This is all fine and dandy as long as ydots > xdots, which it is for real video modes, but not necessarily for disk video modes. The same array is only indexed by what looks like an x coordinate, so I think this is a typo and should be xdots and not ydots. I will make this change on the branch; should it be fixed on the HEAD? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich,
In this function, there are two arrays that are carved out of extraseg: same and colour.
What are the maximum indices into these arrays?
The same[] array appears to be indexed from 0 to xdots.
However, when colour is carved out of extraseg after same, it is done with this code:
same = (int far *)MK_FP(extraseg,0); colour = &same[ydots];
This seems to carve out an array for same[] that is ydots long. This is all fine and dandy as long as ydots > xdots, which it is for real video modes, but not necessarily for disk video modes.
Hmm. I think all we have is pointers. The colour pointer starts at an address that is ydots integers after the starting location of the same pointer. You are correct, if ydots <= xdots, we'll overlap the data.
The same array is only indexed by what looks like an x coordinate, so I think this is a typo and should be xdots and not ydots.
I agree. From the patch history, it looks like Tim worked this magic (patch 1826p12.dif), although the original code is by Paul (de Leeuw). They may be able to add more insight.
I will make this change on the branch; should it be fixed on the HEAD?
It looks to me like it should be fixed on the HEAD also. Jonathan
Rich, here's some beta 3 testing info: [-II-] disk video still crashes fractint when you alter image dimensions after the rendering is complete.. this time it made some dump, so i'll send it to you off the list.. [-III-] VESA behaviour changed - no more "insufficient memory" error, but nothing is plotted anyway, and at the <del> screen, the mode looses its dimensions.. ..doesn't happen with virtual=n by-pass, i recommend setting the global "virtual" to 0 in common \ cmdfiles.c: static void initvars_restart() /* <ins> key init */ { ... virtual = 0; } because this gets also called upon startup, so it overwrites xfract and winfract initialization to 0.. [-IV-] using preview window sets the main fractint window to 320x200, thus the preview ends up being half-way off-screen.. happens when you change the <v> screen pars for the 2nd time.. ..and now for something completely different: [:stereo.c:] ..notice that the only loop that writes to colour[] array goes from x towards 0, so even if same[] and colour[] overlap, it doesn't necessarily overwrite the data in use.. it would happen only if following conditions are ever met for the line "colour[x] = colour[same[x]];": same[x] < x && same[x] < abs(xdots - ydots) && the colour is supposed to contain values from the previous round, which it should not be, as at the very first run it would read from an uninitialized area.. actually, those arrays could overlap completely.. /charlie/
In article <1573.2165-14908-294160381-1170704843@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
[-II-] disk video still crashes fractint when you alter image dimensions after the rendering is complete.. this time it made some dump, so i'll send it to you off the list..
I couldn't repro this, so if you could email to the list specific step-by-step instructions that would be good. The dump files are non-zero now, but apparently I'm still doing something wrong as I don't get stack trace information which is why I implemented them in the first place...
[-III-] VESA behaviour changed [...]
VESA is irrelevant now, so it'll just be removed. There's not any point in trying to make it "work".
[-IV-] using preview window sets the main fractint window to 320x200, thus the preview ends up being half-way off-screen.. happens when you change the <v> screen pars for the 2nd time..
I'm not really sure what you're saying here, so step-by-step instructions on how to reproduce this would be good. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Richard wrote:
[-II-] disk video still crashes fractint when you alter image dimensions after the rendering is complete..
I couldn't repro this, so if you could email step-by-step.. I don't get stack trace information.. (dumps)
ok, so: start fractint, pick any disk video mode (e.g. 320x200), let it render, wait for completion, then go to the <v> screen, change 320 to 32, submit it -> crash
[-III-] VESA behaviour changed [...]
VESA is irrelevant now, so it'll just be removed. There's not any point in trying to make it "work".
i was not talking about making it work, but about preventing it from messing things up -- just make it off by default now.. the removal may take a while, but this would have an instant effect.. it's not about VESA, it's about <v> screen malfunction.. anyway, i still believe that full screen and virtual screens are worth of consideration even in windowed desktop.. as an option, fractint would switch to it upon your request..
[-IV-] using preview window sets the main fractint window to 320x200, thus the preview ends up...
I'm not really sure what you're saying here, so step-by-step instructions on how to reproduce this would be good.
start fractint, pick a video mode > 320x200, render mandelbrot, go to the <v> screen, "Preview display?" -> "yes", <Enter>, so far OK, then again <v>, (change nothing), <Enter> -> fractint window resized to 320x200 /charlie/
Thanks Charlie, I'll look into these tonight. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Charlie Chernohorsky wrote:
anyway, i still believe that full screen and virtual screens are worth of consideration even in windowed desktop.. as an option, fractint would switch to it upon your request..
I agree. I want to play with full screen Fractint graphics without title bars, task bars, etc. I find them distracting with working with images, and besides they cover up part of the image. Lee
In article <45C7C831.7040605@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
Charlie Chernohorsky wrote:
anyway, i still believe that full screen and virtual screens are worth of consideration even in windowed desktop.. as an option, fractint would switch to it upon your request..
I agree. I want to play with full screen Fractint graphics without title bars , task bars, etc. I find them distracting with working with images, and besid es they cover up part of the image.
I hear both of ya, I truly do. But I gotta be honest and say there's still more plumbing that needs to change before those things are going to materialize. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
But I gotta be honest and say there's still more plumbing that needs to change before those things are going to materialize.
Folks, patience. Rich is adopting a development approach that requires discipline but has the best chance of success. That is to make a literal port of fractint, old interface and all, to Windows, and defer the enhancements until later. Rich is doing remarkably well, and I'm not sure who else has the combination of motivation, knowledge, and programming skill to have attempted what Rich is doing. Those of you giving feeback are providing a tremendous service, because we are in a serious debugging mode. Your role is critical, and your feedback very helpful indeed. But please hold off requesting new features or a new interface for the time being. I'm not suggesting you can't talk about it on list, just realize that the development focus isn't there yet, and Rich most likely isn't ready to respond. More Rich quotes:
It would be pretty easy to add them right now, but I'm reluctant to > divert my plumbing activity into new features until the plumbing is > done.
COuldn't have said better myself <grin!> This isn't to throw cold water on those of you hot to add true color and PNG and other goodies, we'll figure out a way to get going soon. Right now the focus is on getting broken things to work, and getting the speed close to the DOS version. Tim
In article <45C785F7.27564.1F53D6@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Those of you giving feeback are providing a tremendous service, because we are in a serious debugging mode. Your role is critical, and your feedback very helpful indeed. But please hold off requesting new features or a new interface for the time being. [...]
Oh, you can request all you want :-). Just don't expect much movement on those things in the near future! I added into the source tree an old "to do list" that I created back in 1999. I didn't review it comprehensively, but I don't think any of those items have been done :-). So we can just add to that list, but most of them will go much smoother and faster when I'm done with this restructuring. The existing list is here: <http://www.xmission.com/~legalize/fractals/fractdev/todo.txt> IIRC, this list was created by consensus and input from the developer list back in '99. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <1577.2169-28095-113804108-1170718413@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
ok, so: start fractint, pick any disk video mode (e.g. 320x200), let it render, wait for completion, then go to the <v> screen, change 320 to 32, submit it -> crash
This is a memory bug that is present in the original fractint, but just doesn't cause a crash there. It simply scribbles over memory it shouldn't. If you run the DOS fracting with debugflag=10000 and use 32x200 for a disk video size, you'll get lots of "out of bounds" messages. Once again I've reproduced the original DOS bug in the Win32 port... At the moment, I'm not sure how to fix this because I haven't spent time reverse engineering the disk video support to know where the bug is in that code. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <1573.2165-14908-294160381-1170704843@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
[-IV-] using preview window sets the main fractint window to 320x200, thus the preview ends up being half-way off-screen.. happens when you change the <v> screen pars for the 2nd time..
This is fixed. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (5)
-
charlie chernohorsky -
Jonathan Osuch -
Lee H. Skinner -
Richard -
Tim Wegner