usrlocalben / pixeltoaster Goto Github PK

If you set the listener then close your display, and re-open in, you need
to manually set the listener again.

listener should remain set once you set it, across any number of open/close
cycles

if you implement a listener to get input, but dont override on key down, --
you expect behavior to not change, but currently this is not the case, as
the quit on escape is ignored.

fix: make the onKeyDown return true/false -- true is default, and indicates
that any "system keys" that are pressed indicating close (eg. ALT-F4 or
escape), should be interpreted as close by default, on top of your existing
keys

this can be made much faster by doing the floating point to integer trick
in reverse

the image display will output in TGA or RAW files each time pixels are
updated to the display.

you can use the image display to record a video of your graphics output

size critical programs such as intros often want to remove dependency on
crt - it would be good to provide a #define PIXELTOASTER_NO_CRT to strip
out all usages of crt functions to help these guys out

this mostly reduces down to providing some way for the user to supply a
custom allocator

at the moment it always centers the window on the desktop

need to install better CAPTCHA plugin for phpbb - bots can just breeze right on 
in past the current 
one

for example, on windows you may have the choice between DirectX and OpenGL
display - on unix you may have a choice between xlib and ggi/svgalib,
directfb or whatever.

a static system interface should be able to enumerate the displays
available on the platform and let you select the current display
implementation to use at runtime, each display you create afterwards will
use the selected display

you should also be able to use defines at compile time to enable/disable
displays on a platform - for example, you may only want to compile in
DirectX and not OpenGL

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.

update the documentation on the website or remove it completely, always ship 
updated doxygen 
documentation with official releases -- that way the users always have relevant 
documentation 
available for that version

implement a basic frontend website on pixeltoaster.com focused around the 
following actions:

1. brief description... more info? -> code.google.com page
2. download latest release
3. support? -> forums, bugs/feature requests? -> add issue on code.google.com 
page
4. documentation -> link to online doxygen docs
5. licence info -> link to full LGPL info

need cool logo! =p.

would be good to have a callback on display open succeed, display open fail
- probably more that would be useful (on display resize is a possibility?)

right now the website does not mention floating point color, since this is
such a large feature of pixeltoaster, -- it should certainly by mentioned!

this is a large feature, but is probably achievable in about a week given 
reference source code - 
more difficult is working out the "best api" to use, as i am not as familiar 
with macosx as win32. eg. 
vfw vs. gdi vs. ddraw vs. opengl vs. d3d --> there are equivalent choices on 
macosx platform 
(quicktime, gl, carbon, core image etc.)

i believe this has something to do with how i setup the windows callback, or 
handle some messages 
- it should be easy to fix, while i'm at it i should create an example program 
that demonstrates this 
behavior

create a new source release ASAP

then write some ruby scripts to package a nice release for win32 including 
precompiled binaries etc. 
one release for mingw32, another for win32 visualc7 etc...

releases should include release notes (PDF generated from open office) - 
release notes include a 
link back to the project website, forums etc. list the features in the build

but most importantly, for each platform explain how to compile and run the 
example programs - 
especially macosx x11 needs this explanation for new users

instead they should be nicely cascaded on the desktop by default.

long term it would be nice if it was possible to specify the x coordinate
at which the display window would initially be created so you could lay out
multiple display windows on the desktop.

win32 issue only - need to check if this still occurs

currently displays are always opened on the primary display, it would be
cool to add a static "System" object which could query how many displays
were attached to the system, what resolution they are, and "select" them so
you could create a pixeltoaster display on each

mine old gfx source code to create some cool demos to implement for
pixeltoaster

can probably strip the whole thing down to a cool "vj" demo

i tried to do this myself, but got a 500 error when trying to run the
install/upgrade_to_latest.php

this is because its trying to switch to fullscreen display, but there is no
matching display resolution so it fails to open the display

the only exception are examples that output to the console such as
"Events", and "Timer"

its annoying to see a console window pop up when you just want to run a
program -- however, making this happen under visual studio is annoying,
requiring that we replace main with WinMain =p

not sure if this still occurs, brought over from bugs list in source
doxygen - win32 platform only.

should be able to return true to indicate that closing is OK, currently you
have to manually close using a flag, which is frustrating when you just
want to quickly get input

error 500 occurs whenever a missing file is requested

the code for converter testing is crude and needs to be cleaned up

i'd also like to be able to go "make test" to build and run the tests

also: additional unit tests should be added for each class in pixeltoaster, to 
ensure it works 
perfectly

this is required to make fullscreen output reliable across multiple
platforms. at the moment, if the exact resolution is unavailable, the
fullscreen display open fails -- but the user has no way of querying the
set of display modes available. THIS IS LAME

FIX IT! :)

tidy it up, add more useful information and fill it out a bit -- its a bit
sparse now

very annoying, the cursor often shows up for a second or so, or stays up
until you move the mouse cursor

a more reliable way of hiding the mouse cursor is required.

at the moment the solution/project only builds a single demo program (rose)
- they should be refactored to build all demo, example and test programs.
i'll need to find some way to organize this, maybe with a makefile project
instead of a project per-EXE, otherwise it'll get annoying

no point adding altivec now that apple has gone intel, so lets spend the
time optimizing for SSE2

we should use NASM for the assembler, and add a #define
PIXELTOASTER_USE_SSE2 which interfaces to the external assembly routines.

initially we should focus on the key conversion routines, eg. floating
point color -> integer, as these are pretty slow at the moment, as they are
pure c++ (however, they are as fast as possible for c++ impl!)

next, we should optimize common cases of 32bit -> 24bit/16bit etc.

probably related to surface loss, doing this to get to the login screen
will lock up -- need to track down.

What steps will reproduce the problem?

1. Open a Display with Output::Fullscreen on the Unix platform

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

Display should go fullscreen, but it stays windowed instead.

When X11 client and server are on the same machine, there's a redundant
frame buffer that might be avoided by using SHM.

add the old string demo in java as a demo program -- shows off cool mouse
based interaction with program

the title of the display is the directory which is opened and the files are
written to

this allows you to record high quality videos of your pixeltoaster rendering

software rendering depends on CPU power, most architectures are going
multi-core

it would be a good idea to add some basic threading support to pixeltoaster
so this CPU power can be accessed in a portable way

there should be queries for the number of cores available, and to create a
thread with an optional affinity to a core -- there will be a restriction
that display open and update must occur on the same thread, but rendering
may occur on a different thread, provided you use synchronization.

What steps will reproduce the problem?

1. run "events" example
2. resize display window
3. move mouse over window 

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

mouse coordinates are reported in exact window coordinates, instead they
should be resized to always be reported relative to the initial width and
height the display was opened at.

current release does not include doxygen documentation, in order to get it out 
as quickly as 
possible - i will create a later release (1.3.1?) with doxygen documentation 
included

this will be particularly awesome for raytracers and other slow processes
that update a line at a time -- for example, the biggest bottleneck in the
"fractal" demo is the high cost of copying the entire framebuffer each time
a line is rendered

should be deferred until after open, for consistency

win32 implementation copies from source buffer into surface, then copies that 
to vram - investigate 
lock/unlock approach allowing direct writing to 32bit (or floating point) 
buffer, providing optimized 
codepath when no conversion is required

at the moment, the user has no control - its always shown in windows mode,
and its always hidden in fullscreen.

pass over all API source code, check coding convention, cleanup my code -
leave bramz's unix code alone according to his code style

mostly involves uniformly converting void blah(int blah) -> void blah( int
blah ) consistently across the code, and checking over all the code for
bugs while cleaning it up

oh yeah, i remember seeing a demo do it. should be possible -- probably
using gamma or someshit

once the new source releases are available from www.pixeltoaster.com, remove 
the download links 
from the sourceforge project -- otherwise people will get confused

the nearest match could be used with the display centered on the screen,
this should be relatively easy to implement - and will fix problems of not
being able to go into fullscreen mode on alt-tab in win32 (eg. see flower
example)

this lets a single object listen to multiple displays

right now, there is no easy way to listen to multiple displays :(