roestvrijstaal / grafx2 Goto Github PK

Suggest to make the grid settings persistent, either in the .ini or .cfg 
file.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

This setting has no effect. Only Windows has system directories, and "show 
hidden directories" will display them already.

Affects:
Setting screen: "Show system directories" button

There are two unimplemented features : rectangle gradients and text.

Rectangles gradients should work with a rectangle as usual, then a vector 
(line) to indicate the gradient's speed and direction. Maybe other modes 
can be added.

Text can be done either with truetype things (somewhat complex with SDL, 
but supported), or with bitmap fonts like the config tool with the same 
library, SFont. In this case, providing features such as rotating, 
zooming, scaling, and so on, plus some default fonts. Maybe we could use 
some kind of vector path and draw with brushes following the path, may 
enable interesting effects, but, will be horribly long to render. As with 
other operations, a preview mode will be useful :)

1. Draw some shapes
2. Pick a big rectangular brush (B)
3. Enter magnify mode (M)
4. Use your brush to draw wild shapes in either the normal or zoomed view. 
--> On both views, it looks as if you drew with a zoomed-down version of
your  brush
5. Scroll right or left with arrow keys
--> The drawing area updates with the right brush size : it was "only" a
display feedback error.

Tested in several drawing modes (normal, smoothe, stencil..), all are affected.

This doesn't happen with any of the built-in brushes (that are monochrome),
only user-picked brushes. Also, if you pick a brush and transform it to
monochrome (right-click on the brush picker icon), the problem doesn't
occur. It's specific to colored brushes.

What about some simple mouse wheel functions, such as scroll/shift+scroll
for scrolling along x/y, alt+scroll for zoom and ctrl+scroll for brush size
(or something else?).

Drawind anything on the screen will not be visible because we miss an 
updateRect somewhere.
However, having an updateRect occur each time a pixel is changed will be 
very slow. We need to find a good slution for that

User configuration (gfx2.ini, gfx2.cfg) :
It might be better to store them in ~/.grafx2/ (linux)

Program and Data:
After a "clean" installation, the main program(s) may reside in /usr/bin, 
so the remaining of the data (gfx2.dat, system font...) may be 
in /usr/share/grafx2, I suppose.
I'm not completely familiar with this, but as I understand it, the linux 
end-user would compile normally in a temporary directory (make or make 
NOTTF=1); then su root and run "make install" that creates the required 
directories, copies (or moves?) all files to their target directories, 
chown as needed. I suppose a "make uninstall" makes sense too.

To make it work and still allow easy development, the program would need 
to check several directories: if the files are in the program's directory 
it's a fresh compile or SVN workshop, so these ones should be used in 
priority.
Also the program would need to create ~/.grafx2 at runtime as needed, 
since it's not always the same user.

I mark this Milestone 2.0, because the config files are going to change 
again, and even the .dat may need rethinking.

Opening files:
http://www.cpcscene.com/GrafX2/GrapfX2-OpenDir.png

The drive list is disabled:
-> Windows: I will read list from GetLogicalDrives(), though it won't make 
a difference between floppy, hdd, cd.. (I can assume A and B are floppy, 
though).
-> Linux: I can hard-code 2 icons, one for / (root), one for ~ (the 
current user's home)

".." Not listed in directories
-> Need to add. In the mean time, you can use backspace key.

Cannot change directory or save/load if name > 27 characters
-> The max visible string is 27 characters and cannot be increased 
indefinitely. I will enable editing of strings longer than the visible 
space, making the text "scroll" left or right as needed to keep the cursor 
in view.

Filenames still shown as 8(abbreviated)+3.
-> I'd like the 8th character to be some sort of "..." character if 
possible. dependent on the characters available in the fonts.

The recent change in the Save/Load box filled the source code 
with "variable" coordinates, like (9*8)+..., and FILENAMESPACE+...
-> When everybody's happy with the Save/Load box, I'll turn these back to 
hard-coded litterals. Right now, the variables help a lot in finding the 
places where controls are drawn.

Text input (filename, comment) doesn't like special keys.
-> Requires a big fix in how the keyboard is read.

http://pouet.net/topic.php?which=5703 / Lord Garga
"
Drawing lines leave some ugly artifacts.

Any chance of drawing only horizontal, vertical, and diagonal lines when
holdning down shift?
"

We could use libpng.

Or there's a img_savepng.c, a kind of complement to SDL_image.
One source:
https://svn.berlios.de/svnroot/repos/enigma-game/branches/1.0/lib-src/enigma-cor
e/IMG_SavePNG.h
https://svn.berlios.de/svnroot/repos/enigma-game/branches/1.0/lib-src/enigma-cor
e/IMG_SavePNG.c
License is apparently LGPL.

The program should be able to switch between fullscreen and windowed mode.
Either add
  * A command line switch, a keyboard shortcut and a button on the screen 
prefs window. May require modifications to the config file, thus a rework 
of the Turbo Pascal tool used to generate it,
  * A field to the screenmode struct. Maybe use the "freq." field wich is 
irrelevant in SDL, or add a new field.

This is important because fullscreen allows to use non-square pixels on 
CRT screens, but most of the strange modes will not work with newer LCD.

The program always boot in windowed mode. Allow users to select a different
mode and save it in the config. file.

Moving the cursor over the menu icons displays a text "tooltip" in the 
bottom "status line", showing the function. There's no drawing problem 
when changing icon, the new label cleanly replaces the previous, no matter 
how long the strings are. ok.
Now, if you go down to the status line itself, the text is replaced by a 
blank, BUT not refreshed.
It's not easy to see because the cursor immediately disappears as it's too 
low (see previous bug) and doesn't refresh what it's hovering on. You need 
to be at the exact Y position to see the cursor AND be on the line, and 
then you'll see your cursor erase the text under it.

Seen on Windows. Not related to recent changes.

When running in windowed mode, there is no minimum size. 320x200 seems a 
good idea.

Add some constraints to the window resizing so one can always see the full 
palette and the toolbar, plus some part of the picture.

Build a simple layer system allowing to work with some pseudo transparency 
("magic pink", or alpha-bits, or alpha-plane).
See what is possible when using only 256 colors

The original authors' clearly state their intent to release the software 
under the GPL in readme.txt, but the "credits" menu still shows the text 
from the earlier license (giftware), with the notice "(GrafX2) cannot be 
modified in any way without our written consent."

Also, we should put a copy of the GPL text in the zip packages we put up.

Holding a key does not repeat the action at all.
It's annoying while drawing (ex: arrow keys to scroll), and when entering
text in a box (ex: backspace in filename input)

The behaviour of the DOS version was consistent with the user's typematic
settings, the ones you set with MODE CON RATE=32 DELAY=1

Some functions (mostly in op_asm.c) are not used anymore because we 
disabled "assembly optimisations" (and there is no assembly code anymore). 
We should find and remove them, however, some of their C counterparts are 
broken (Floyd Steinberg dithering doesn't look at all how it should, for 
example.
So, maybe some of them would be handy to have around in some place ...

The keyboard isn't working at all.
The get_input function in Divers.c should do what the old get_input did, 
but using SDL.
The behaviour is descripted in the "input handling" page in the wiki. Look 
at it and make the keyboard work :)

The existing "help" reader can easily be re-used.
It's text-only, though.
We could use it to display a help paragraph depending on the window: 
Effects, Palette...
The documentation already exists, in French and English, in the docs 
folder: It's only a matter of selecting the right paragraphs and 
formatting them for 44 characters wide display.

The help reader could be invoked by using a shortcut key. It seems 
difficult to add a '?' on each window because of their layout.

When doing a make, the makefiles recompiles everything for me, even if i 
changed a single file.
Use a proper buildsystem and avoid wasting my cputime :)

Maybe switching to Jam or scons or ... or maybe the regular autoconf system 
may help there, as the makefile is starting to get a bit messy with amigaos 
changes integrated in it...

I'm thinking of a way to make GrafX2 powerfully edit multi-frame images, 
without hurting the usability with normal images.

The program would still have 2 images (Principal & Spare) loaded at same 
time, TAB still switching between them. but now an image would comprise of 
1 or more frames.
All frames of an image share the same palette and dimensions. At any given 
moment, only one frame is displayed (ie: #05)
Some keyboard shortcuts help quickly navigate to previous and next.

An extra screen allows showing and editing the "strip" of images (clone, 
del, displace ), setting each image speed, previewing the animation.

Difficulties:
Need to adapt Undo. Especially because an operation like Resize affects 
the pixel data of all frames.

Bonus:
Even for normal pixelling, a multi-frame Spare page can help memorize an 
important stencil and restore it later.

After loading an image that causes a screen resize (down), the Save/Load
screen doesn't refresh (visually) normally, and it doesn't take mouse input
at all. Keyboard entry is fine.

I suspect a Menu_Facteur_X / _Y that is incorrectly computed.

The mouse cursor in GrafX2 is drawn on screen with a software routine, 
pixel by pixel. This is very slow and needs the screen to be updated at 
each mouse move.
We should make the mouse handling routine use the real SDL cursor wich is 
much faster.
We need to change this cursor with the appropriate functions in the GrafX2 
engine instead of the software one, wich should eventually be removed.

The file graph.c is more than 6000 lines long, making the issue tracker 
diff tools and the developpers find out their way there.
Split it up in two or more files, but keep some logic about what goes 
where.

The rotated XOR cursor in graph.c 2200-2700 functions uses XOR lines and
does not update the screen. May lead to some garbage being displayed or the
cursor invisible.
Easy to fix, there are 4 XY coordinates (4 corners of the rotated
rectangle), sort them and update the big rectangle (xmin/ymin - xmax/ymax).

The usability of this feature is questionable.
The idea was that if you opened a 320x400 image, it would auto-select the 
according Mode-X which has the very "flat" pixels.

I don't recommend for any user to activate this feature, because nowadays 
we have no platform that provides such modes.
My laptop LCD, on linux, is the only one that accepted all the default 
GrafX2 "resolutions". I configured it to not stretch images, so it centers 
the area and displays black borders, doubling pixels when possible. All 
modes look good but in all cases the pixels are square and I have no 
reason to choose a smaller drawing area, so no reason to let GrafX2 choose 
depending on picture size. I'd rather choose manually one of the two 
fullscreen modes hi-res 1024x768 and low-res (very pretty!) 512x384.

Affects: settings screen "Auto-set res"
INI: Auto_set_resolution
INI: Set_resolution_according_to

On a XP machine with few detected resolutions (window + 5 fullscreen), the 
6 remaining lines show a dummy "0x0 windowed mode".
Trivial to fix.

GrafX2 runs very slow under mac os X.

Find why, and make it faster :D

Polyfill needs call to Mettre_Ecran_A_Jour when filling.

I built svn 244 on Ubuntu x86_64. Trying to run gfxcfg results in a black
rectangle momentarily appearing, then exiting with "Segmentation fault." on
the console.

Assign the icon to the program with SDL_WM_SetIcon()

Rather than shipping the icon as a separate file, I'll see if it's 
possible to append it to gfx2.dat, just before the ini file.

Create a color brush, draw with it in zoom mode.
The zoomed part will not update as it should.
Tested with a brush not fitting the screen. May work with small ones. 
Check Mettre_Ecran_A_Jour clipping to screen system.

Wait_VBL() in divers.c waits for 20ms (1/50s), instead of a real VBL-time. 
There is no way in SDL 1.2 to wait for the VBL, but we should get the 
refresh freq and compute the real delay.

Although gfxcfg doesn't work, I managed to run grafx2 on 64-bit Linux by
using a DAT from the precompiled binaries.
However, editing colors in the palette is painstakingly slow, to the point
of being unusable.

The Grad Rectangle is completely drawn even if it exceeds the drawing area.
On the rigt it comes back on the left side, but on the bottom it overwrites
the menu, and can even segfault if it exceeds the image area.

Grafx2 internals use a VGA palette with values in the 0-63 range. However, 
SDL can display colors in the 0-255 range. This should be enabled (maybe 
as an option), but we'll have to modify the loading/saving routines and 
create a variant of the PKM files. There is a version number for that. The 
old grafx2 under dos will no more be able to load our pictures, tough.

The mouse settings should generally be removed, because SDL already 
receives "clean" information from the OS.
Currently, Sensitivity is ignored, but the mouse is unusable if 
correction_factor isn't left at 0.

Screen "Settings": 2 sliders "Mouse sens"
INI: X_sensitivity
INI: Y_sensitivity
INI: X_correction_factor
INI: Y_correction_factor

Saving and loading files uses direct read/write of struct to file. This causes 
problem because there are 
gaps between members wich should not be written to the file.

Replace the direct read/write of structs by read/write of each members one 
after each other.

When working with a low-color image (I mean even lower than 256), or when
using an "exotic" graphics mode, it would be convenient to be able to
choose the width and height (in cells) of the palette situated in the lower
right corner.

SDL_UpdateRect tends to segfault and pdateZoom is buggy. Replace them 
where applyable by Mettre_ecran_A_Jour.

The "sprite" cursors, like the triangle arrow, are not drawn at all when 
they would be clipped at the right or bottom of the screen. They disappear 
completely as soon as they touch the border, which can make it difficult 
to pick colors in the bottom palette row.

Very old problem, happens in Windows, not sure for other OSes.

(Tossing ideas around)
SDL cannot catch tablet-specific values, unfortunately ...
However, it reports 3rd button and mouse wheel, and both are very common 
hardware nowadays.

3rd button ideas:
Some people may like Color picker, or Magnify on/off

Wheel ideas:
* next forecolor, previous forecolor
* bigger brush, smaller brush (concerns internal brushs like square, 
round, slash...)

It may be the most useful to let the user assign any function to any of 
those 3 "buttons". Gfxcfg can be modified to let the user set his mouse 
button preferences.

Select a colored background color.
Hit B (Brush grab)
On the picture, click and hold the Right mousebutton, move to select a big
rectangle, and release button.

--> The selected rectangle is "cut" as a brush, replaced by the current
background color. But the refresh/update on this rectangular area is not done.
Happens in normal view, and in both pannels of zoomed mode.

What steps will reproduce the problem?
1. Draw some things
2. Zomm on them
3. Change the zoom factor using the magnify menu

What is the expected output? What do you see instead?

The zoom part of the screen is not updated.

Some values are stored in two variables. For example, when drawing an 
ellipse, we use Ellipse_Limite_High and Ellipse_Limite_Low to store the 
value. Should be only Ellipse_Limite, 64bit (uint64_t, or __int64, for 
example).
Refator the code accordingly

gfxcfg.exe complains that it can't find jpeg.dll, java.dll, jvm.dll and 
verify.dll

I downloaded some versions from an online dll repository, but they weren't 
the correct ones.

I'm on Windows XP SP2, using GrafX 2.00b97.0%

The main program, grafx2.exe, works just fine.

Best Regards
me

From the original authors of beta 96.5% :

WHAT WE STILL HAVE TO DO TO "COMPLETE" GRAFX 2.00:

    - Rectangles filled with gradation
    - Distort brushes
    - Allow to use HSB values to define colors.
    - FX on the picture (flip, stretch, shrink, ...)
    - Text (we hope we'll be able to use TrueType fonts)
    - Improve clicks on buttons in the menus (don't block the mouse).


OTHER POSSIBLE IMPROVEMENTS:

    - Add "Anti-aliasing" mode.
    - Add more drawing modes.
    * Support Windows 95 long filenames. [DONE]
    * Add more video modes and fix some others. [DONE]
    - Add PiNG, TIFf, TarGA and JPeG file supports (in our dreams ;)).
    - Allow to load more types of truecolor pictures with Dithering or
      Floyd/Steinberg color reduction.
    - Add Pop-up menus.
    - Palette sort.
    - ...
    - Fix unknown (and known) bugs! :)


Note: There is no special order for the things to do listed above.