Closed stuaxo closed 2 months ago
LegalizeAdulthood
commented
8 years ago Currently, the only platform that really works is Windows. The linux port is a work in progress. The X11 driver is incomplete at this time, but it is on the release plan for the next version. I'd be happy to discuss my plan for that if you'd like to contribute :smile_cat:.
stuaxo
commented
8 years ago I'm interested in fractint, but don't have a huge amount of time... would you consider SDL2 to abstract out the platform differences ?
I've had a long time to think about what I'd like in a modern fractint so will definitely have a poke around :)
LegalizeAdulthood
commented
8 years ago I hear you about the available time thing :). This has been an on-and-off project for me for a bunch of years already, LOL.
The current plan is to get the minimal X11 support through the existing driver abstraction. The main thing missing right now is the ability to display a CGA style text window for the UI. Xfractint uses curses and requires you to run it in a terminal window with the graphics displayed elsewhere. On Windows, I create my own CGA style text window and display everything in the same window. that was the path I was on for the linux port, using Xlib directly. I have made some progress on the x11 branch of the repository, but it still needs more work to finish it. I might try and finish that off during the Christmas/New Year holiday break.
SDL looks interesting for the graphics part. Does it have a GUI toolkit like Qt or wxWidges? My current plan is to use wxWidgets for the GUI framework and use wxGLCanvas for the graphics.
Currently the code use a DOS style polling for keystrokes mechanism to handle the UI. The flow of control needs to be inverted at some point to switch the code to being event-driven. There's a way that this could be done that most of the existing code doesn't change; it still thinks it is polling for keystrokes but in reality it is just draining the message queue when it polls. Over time it would be refactored to be more like a traditional event-driven GUI code base.
The graphics demands of the existing code can be satisfied entirely with "get pixel" and "put pixel". However, the L-systems and other line-drawing code should be using line primitives directly instead of hand rasterizing them into pixels as is done currently.
I had some offline discussions with Damien Jones about things and he convinced me that putting a modern GUI on things was more important than I had initially planned, so I moved that up to the 2.0 release from where I had it before. The most recent thing I've been doing was trying to get the help files converted to use the sphinx documentation system for better visibility on web searches. There's a lot of good stuff in those help docs, but it is effectively "dark" on the internet. I did a crude conversion of the doc file for github to at least get it searchable by google, but it's not in the most browsable form right now.
stuaxo
commented
8 years ago SDL doesn't have a widget set, but what it does have is a standard way of getting a GL conext setup, some sound support (though I'm not sure if that's enough for fractints sound).
A major advantage is that it would then easily be buildable on android, and wayland when everyone moves to it (+ windows and macos, but you have native drivers for these already).
get-pixel and put-pixel would get things working fast. How things are organised in memory affects speed ...
Tiled organisation should be the fastest because of better cache coherency, and offers a path towards multithreading / multiprocess.
Separating fractint into a library that provides a minimal amount of calls to render a fractal/par to memory would probably make it the easiest to try different GUI approaches + integrate with other programmes.
(I guess if there could be some sort of async call to start a fractal / part of a fractal rendering and the ability to cancel ?)
A modern UI should be organised differently to the current text-mode UI - which would need some thought; e.g. how do you organise things wrt the different fractal types + the par files, currently under '@' and 'T'.
Some things worth investigating in a modern GUI, might be semi realtime zooming, a-la Xaos, and some sort of visual parameter changing, like gnofract4d.
Converting the help to sphinx sounds great.. I'm guessing a bit of a PITA, are you writing a script to do it?
Turned into a bit of a brain-dump, but there you go :)
LegalizeAdulthood
commented
8 years ago The sound needs for fractint are really simplistic. I was looking at some sound cross-platform libraries but didn't try anything out yet. I don't think sound is one of those things that many people use, particularly since it is so "beep boop" in its approach to sound synthesis.
I am interested in having the code more adaptable to mobile devices, android in particular. When I last looked at the android SDK, it looked like you could have native code for "crunching" but that you still had to do all your UI in Java. Is that still the case?
I agree that separating the computation from the GUI is a good idea. Splitting out the computation and GUI into separate libraries/modules is part of the long-term roadmap, but I just noticed I don't have anything stated that on the roadmap in the wiki. This also facilitates distributed rendering. Hexagonal architecture is the way I had planned on going--the computational part becomes the core and whatever sort of "interface" is needed to interact with the computation becomes an adapter. Distributed rendering then becomes just another adapter on the core, as does an android GUI, wxWidgets GUI, etc. This is a ways out from where we are today in the code, but it's the direction I'm trying to steer the ship :smile_cat:.
While the current graphics model is "memory mapped framebuffer", this has to transition to something more GPU friendly, particularly if 3D fractals are going to be more directly rendered by the GPU. Currently all 3D and line drawing is done in software to boil things down into pixels. The plan is to transition all screen rendering into OpenGL. There will still be image buffers flying around in memory in the core. Those might transition to wxImage or remain some sort of internal structure.
Regarding changes from the text GUI to a modern GUI, I agree with you there as well :smile_cat:. I would like to switch from text-oriented browsing (names of fractal types and names of parameter sets) to a more visually oriented browsing (every fractal type should have a canonical image, thumbnails for parameter sets, etc.). There is some of this currently in the "browse mode" where given a fractal type and a bunch of previously saved GIFs it will visualize the extent of the rendered images in your current view. This is a start, but we need much more visual browsing support. There is some overlap here with "evolution mode" as well.
Real-time zooming a la XaoS is something I've wanted for a while as well. I even have some ideas on a multi-resolution caching data structure that I think would improve on the navigational speed over XaoS, but I haven't prototyped or benchmarked anything yet. I think the key to improving interactivity is decoupling rendering from computation. In XaoS, they are one and the same. If you had previously calculated something in XaoS but it goes off screen, the calculation work is discarded and must be recomputed if it comes on screen again.
If a multiresolution caching structure is done properly, then it should be feasible to have quick browsing on a mobile platform with minimal computation -- you're just browsing previously computed results.
Regarding Sphinx, I've got a node.js script I've been hacking up to do the majority of the structural translation. After that I planned on doing a manual pass through things to finish it off. Then I would commit this to github pages. I'm trying to work out how to get sphinx integrated into the build in such a way that the online help is redirecting you to the sphinx pages. At first pass will simply be to get the existing help source files processed into sphinx. If this can be completely automated (seems feasible), then the amount of manual fiddling is minimal and the existing online help system can continue while github pages get the pretty sphinx output. When moving to wxWidgets, it will move to pure HTML help, either locally or via github pages.
I realize that github issues aren't the best way to have a conversation. If you want to setup a skype conference or something, let me know.
LegalizeAdulthood
commented
2 months ago The code currently builds on ubuntu for continuous integration, but the unix port remains incomplete. This should be resolved when we switch to wxWidgets. So I'm going to close this bug.
I got fairly far building this, but not far enough :/