| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Currently just a memset wrapper... but maybe could get noop'd if
the flipper thread started supporting pre-zeroing pages in its thread,
just need a zeroed state in the fb page.
|
|
drop draw_pixel() duplication
|
|
|
|
discards draw_pixel(), introduces helpers.h and a convenience
function for bounds checking and oob extermination. Move makergb
to helpers.h, draw.h gets removed in a later commit.
|
|
Modules seem to be duplicating this, just pull it into fb.h since we're
already dependent on the fb.h abstractions in the modules. Slippery slope!
|
|
If a z-buffer is added these checks will need to be done independent from and
prior to drawing. Also it's silly to makergb() pixels which can't be drawn.
|
|
Simple x,y coordinate check
|
|
- Move source to src/ subdir
- Use $(top_srcdir)/src instead of ../../
|
|
The relative path broke out-of-tree builds.
Previously the following:
$ mkdir /tmp/foo
$ cd /tmp/foo
$ ~/src/rototiller/configure
$ make
Would fail to compile unable to locate the headers in
~/rototiller/src
This fixes it.
|
|
Restoring some organizational sanity since adopting autotools.
|
|
If NUM_FB_PAGES was redefined to 1 rototiller would hang, since 1 is
insufficient for page-flipping.
|
|
|
|
|
|
(78d9c385ae3a1939e059c674ba5649df99d5615c)
|
|
As this stuff is all generated we don't want to ever check it in...
|
|
Not everyone knows about `autoreconf --install`
|
|
|
|
Now the usual ./configure && make should suffice.
|
|
Builds were getting too time consuming, autotools is a very simple way
to get incremental builds without having to dick with Makefiles myself.
|
|
stars: add starfield simulator from ph1l/stars
|
|
|
|
vestigial deficiency from variable gravity experiment
also reduced gravity, the results seem more aesthetically pleasing.
|
|
More of 86bc322, eliminate per-particle unnecessary calls
|
|
This is a trivial optimization which makes a substantial difference.
When we're doing things like explosions, thousands of occupants get
added to the bsp tree at the exact same position. Without the lookup
cache we end up traversing the octree down to its maximum depthrepeatedly,
because the bv containing the explosion is of course full and maximally
deep.
Now explosions don't need to spend a bunch of time in the octree just to
keep locating the same full bv the explosion occurs in.
|
|
|
|
trivial per-particle savings
|
|
|
|
Multiplies tend to be less costly
|
|
Stride needs to be considered as part of width, this is wrong,
funnily none of my test systems exposed it.
|
|
|
|
|
|
With the current checkerboard pattern the majority of the interpolation
being performed is pointless.
Of course with a more complex texture this won't be as beneficial, but for
now it makes a significant FPS improvement.
|
|
Minor formatting changes
|
|
Rather than using whatever the existing drm_crtc->mode is, present all
modes on the chosen connector and let the user pick.
|
|
This implements anti-aliasing, no more jaggies!
Still 100% software rendering, fixed point arithmetic.
Maybe add zooming with mipmaps next?
|
|
reduce some of the silly duplication across 32/64 versions.
|
|
|
|
|
|
Also improves handling of odd situation of no connectors w/encoders
|
|
text: update README and TODO
|
|
|
|
More candy
|
|
This should produce a rototiller executable with all the renderers available,
and the ability to choose the DRM card and connector.
|
|
This will be replacing the old rototiller listings, and uses all the
new stuff (drm_setup, fb, fps, renderers...)
|
|
My first ray tracer, it only has spheres, planes, and point light sources.
No texture mapping, no soft shadows, no global illumination.
This is all very basic right now, the camera movement is simple and boring, but
sufficient for further development and optimization.
I made some effort to support multiple CPUs, it should detect the number of
CPUs in the system and use enough pthreads to keep them busy.
Jacco Bikker's tutorial on flipcode was the original impetus to do this, and
definitely served as a guide early on.
|
|
A while ago I made this particle system on SDL, and had the beginnings of
an octree implemented within it, but never finished actually using the
octree to accelerate the proximity searches.
This now has the octree completed and of course more particle interactions now
that neighbors could be found more quickly.
The simulation somewhat resembles a fireworks display. Every particle is drawn
as a single pixel. The visual effect is dominated by spontaneously spawned
rockets which explode into thousands of particles accompanied by bursts that
thrust particles away from the explosion radially in an expanding sphere
resembling a shock wave. When the shock wave happens to strike another rocket,
it explodes, resulting in another shock wave. This can produce spectacular
chain reactions, so it's worth running for some time and seeing what transpires.
|
|
|
|
quick and dirty stdio-based drm card and connector selection
|
