Rich, At the default image, pressing either o (for orbits) or the space bar gives an out of memory error in editpal.c. Which, makes no sense, since we shouldn't be anywhere near editpal.c. Also, I tried loading an image (using the 3 key) to make a 3-d image and ended up stuck in a loop. Jonathan
On Tue, 2007-03-20 at 20:50 -0500, Jonathan Osuch wrote:
At the default image, pressing either o (for orbits) or the space bar gives an out of memory error in editpal.c. Which, makes no sense, since we shouldn't be anywhere near editpal.c.
Hmm, looks like the common denominator is jiim.c. This file had a lot of changes in it due to the vesa scrolling addition. I'll need to resurrect an old version so I can see what needs to be changed. Jonathan
This was high on my list of things to look at next. Currently I want to finish up the work I'm doing on mouse support. I have it sort of working, but it doesn't really feel smooth. -- "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,
Hmm, looks like the common denominator is jiim.c. This file had a lot of changes in it due to the vesa scrolling addition. I'll need to resurrect an old version so I can see what needs to be changed.
The video_start_x and video_start_y variables were introduced with the vesa scrolling since the visible screen may not have started at the same location as the video memory (due to scrolling). The intent was to maintain the small display window on the screen, even while scrolling. If you don't mind, I'll return this code to the way it was prior to the addition of vesa scrolling. The g_video_start_x, g_video_start_y, g_vesa_x_res, and g_vesa_y_res variables will go away. This shouldn't be a problem since eventually we'll be able to open a new window for the small display. Jonathan
In article <1174610974.3915.15.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
If you don't mind, I'll return this code to the way it was prior to the addition of vesa scrolling. The g_video_start_x, g_video_start_y, g_vesa_x_res, and g_vesa_y_res variables will go away. This shouldn't be a problem since eventually we'll be able to open a new window for the small display.
That would be great! -- "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/>
I removed mem_init and mem_alloc and replaced them with malloc() and free(). 'o' works again. -- "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,
I removed mem_init and mem_alloc and replaced them with malloc() and free(). 'o' works again.
Thanks, that fixed it. The space bar works now, also.
Currently I want to finish up the work I'm doing on mouse support. I have it sort of working, but it doesn't really feel smooth.
Tried it with a zoom box. That's weird! Jonathan
In article <1174603945.3915.4.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
Currently I want to finish up the work I'm doing on mouse support. I have it sort of working, but it doesn't really feel smooth.
Tried it with a zoom box. That's weird!
Yeah, it works, but it doesn't track the mouse properly. The assembly code was *hard* to understand and although there's mouse support in the X11 version, its completely different from how DOS was doing it. It also currently doesn't handle left-click properly. At this point I'm not sure if I should continue to try to emulate the old DOS logic, or do it the X11 way. Neither is the "final" solution for the next stage of evolution so I'm torn about how to do it. I don't want to invest a lot of time in something that's just going to be reworked later anyway. -- "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,
Yeah, it works, but it doesn't track the mouse properly. The assembly code was *hard* to understand and although there's mouse support in the X11 version, its completely different from how DOS was doing it.
It also currently doesn't handle left-click properly.
At this point I'm not sure if I should continue to try to emulate the old DOS logic, or do it the X11 way. Neither is the "final" solution for the next stage of evolution so I'm torn about how to do it. I don't want to invest a lot of time in something that's just going to be reworked later anyway.
Take a look at the Allegro port. I implemented mouse support in it. I suspect it works very much like the X11 version. Are you not retrieving the mouse coordinates with a Windows call? I'd have to look at it, but I would guess that the assembly code is just getting the mouse coordinates with a bios call. Jonathan
In article <1174691787.3913.4.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
Are you not retrieving the mouse coordinates with a Windows call?
You don't need to as they send them in the event. However, events report mouse position in pixels and the BIOS crap is dealing with mickeys and thresholding and a lot of other shit. The giant crazy jumping all over the place is what makes it difficult to understand the assembly. The logic is severely contorted. -- "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,
You don't need to as they send them in the event.
However, events report mouse position in pixels and the BIOS crap is dealing with mickeys and thresholding and a lot of other shit.
The giant crazy jumping all over the place is what makes it difficult to understand the assembly. The logic is severely contorted.
I'll take a look at it tomorrow. Jonathan
In article <1174702762.3913.5.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I'll take a look at it tomorrow.
All the mouse handling is in the mouse message handlers in frame.c; its still trying to push fake keys into the keyboard buffer like the DOS code did, but it doesn't have all that mickey logic that the DOS code had. -- "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 said:
I removed mem_init and mem_alloc and replaced them with malloc() and free(). 'o' works again. [In my personal copy of the developer's Windows port of Fractint.]
[I believe that this 'orbits fixed' version is not yet available in a Windows' beta -- but you can see the Fractint <O>rbits option using the original DOS Fractint using the instructions below. - HHL.] Great! When I use 'o' (orbits) I find that today's processors are so fast and screens so large that the tiny pixels showing all the calculations are lit up so fleetingly as to be barely visible. Thank heavens the writing and 'erasing' of each of the 'iteration pixels' significantly slows down the overall calculation process to let you catch a fleeting glimpse of the 'orbits' pixels... I found that on the original DOS version of Fractint: - reducing the resolution to, say, 800 x 600, - turning off Periodicity on the <Y> screen and - setting Passes = 1 on the <X> screen can make the dancing pixels be large enough to see better. Turning up the brightness and contrast helps. <O>rbits works well on the default Mandelbrot set using a color map like GOODEGA.MAP. You just have to hit that <O> key quickly or the fractal will be mostly completed before it appears on the screen! Thanks for all your work on the program. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Richard Sent: Thursday, March 22, 2007 8:25 AM To: Fractint developer's list Subject: Re: [Fractdev] Out of memory errors
I removed mem_init and mem_alloc and replaced them with malloc() and free(). 'o' works again. --
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.413 / Virus Database: 268.18.18/734 - Release Date: 3/26/07
In article <MDBBJLBFBICIIEIHFBMEIEHIDAAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
When I use 'o' (orbits) I find that today's processors are so fast and screens so large that the tiny pixels showing all the calculations are lit up so fleetingly as to be barely visible.
I believe you can use orbitdelay to slow things down if you want. There are more ways we could visualize the orbit these days, something we could add to the 'todo' list. -- "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 (3)
-
Hal Lane -
Jonathan Osuch -
Richard