summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2019-11-10settings: add a SETTINGS_STR() helper macroVito Caputo
Just a convenience thing as settings are all string-centric and callers like modules will probably have stuff like literal numbers defined for defaults which need to be stringified for setting_desc_t.
2019-11-10rototiller: add rototiller_module_t.setup()Vito Caputo
Wire up support for module settings, yes it's that small a change. I've forward-declared the settings related types in rototiller.h, if a module wants to actually wire up the .setup() method they'll need to include settings.h.
2019-11-10settings: s/setting_desc_new/setting_desc_clone/Vito Caputo
Slight refactor to make call sites less annoying. Now takes a (setting_desc_t *) instead of the members as discrete parameters, and returns an errno on error so callers can simply propagate error codes out rather than having to get access to errno defines, check for NULL and return -ENOMEM etc. It also makes the call sites self documenting by employing designated initializers in compound literals for the supplied setting_desc_t. This is in prep for runtime-configurable module settings.
2019-11-10rototiller: setup_from_args() has defaults alreadyVito Caputo
I think passing this separately is vestigial from before there was an args struct encapsulating everything. In the future there might be some defaults discretion supported to say use defaults for module settings but not video, or vice versa. So get rid of this pointless parameter in prep for that, just use the args struct.
2019-10-16modules/flui2d: fix spelling of paper's authorVito Caputo
s/Joe/Jos/, I should wear my glasses more.
2019-10-14modules/flui2d: add 2D fluid dynamics simulationVito Caputo
This implements near verbatim the code found in the paper titled: Real-Time Fluid Dynamics for Games By Jos Stam It sometimes has the filename GDC03.PDF, or Stam_fluids_GDC03.pdf The density field is rendered using simple linear interpolation of the samples, in a grayscale palette. No gamma correction is being performed. There are three configurable defines of interest: VISCOSITY, DIFFUSION, and ROOT. This module is only threaded in the drawing stage, so basically the linear interpolation uses multiple cores. The simulation itself is not threaded, the implementation from the paper made no such considerations. It would be nice to reimplement this in a threaded fashion with a good generalized API, then move it into libs. Something where a unit square can be sampled for interpolated densities would be nice. Then extend it into 3 dimensions for volumetric effects...
2019-05-19libs/ray: fix off by one error in prepared objectsVito Caputo
Missed the sentinel, oops
2019-05-18libs/ray: trivial indentation fixupVito Caputo
2019-01-01modules/submit-softly: bilerp peripheral cellsVito Caputo
Remove the silly kludge avoiding peripheral cells
2018-12-31modules/submit-softly: shorten descriptionVito Caputo
2018-12-31modules/submit: add bilinearly-interpolated variantVito Caputo
This substantially reworks the cell sampling in submit. As a result, it's now threaded in the rendering phase which now resembles a texture mapper sans transformations. This produces a full-screen rendering rather than a potentially smaller one when the resolution wasn't cleanly divisable by the grid size. A new module, named submit-softly has also been added to expose the bilinearly interpolated variant. The transition between cells is also employing a smoothstep so it's not actually linear. The original non-interpolated version is retained as well, at the same submit module name. Some minor cleanups happened as well, nothing worth mentioning, except perhaps that the cells are now a uint8_t which is fine unless someone tries to redefine NUM_PLAYERS > 255.
2018-12-31libs/grid: fix grid_ops_t.taken player typeVito Caputo
Just making things consistent, also dropping unnecessary player assert from submit module. Future libs/grid may explore using the "unassigned" zero player in taken calls for unassigning cells like in simultaneously taken collision scenarios.
2018-12-30modules/stars: capitalize descriptionVito Caputo
2018-12-30modules/submit: add cellular automata game moduleVito Caputo
This module displays realtime battle for domination simulated as 2D cellular automata. This is just a test of the backend piece for a work-in-progress multiplayer game idea. The visuals were kind of interesting to watch so I figured may as well merge it as a module to share. Enjoy! PS: the results can vary a lot by tweaking the defines in submit.c
2018-12-30libs/grid: add grid cellular automata componentVito Caputo
Prep for adding a new module displaying a cellular automata based on the grid component from a multiplayer game I'm working on.
2018-12-06rototiller: make some local helpers staticVito Caputo
2018-04-03libs: commit missing Makefile.am filesVito Caputo
Oops! This should have made it into b5bc96, been sitting in my tree.
2018-03-19modules/ray: #include libray headers w/subdirsVito Caputo
Rather than require adding -Isrc/libs/$lib to every Makefile.am for every lib used, just add -Ilibs to those makefiles and prefix the lib dir in the #include <> header paths. Later I'll probably just move the -Isrc/libs someplace common so the per-module Makefile.am doesn't need to bother with this stuff.
2018-03-19ray: libize raytracer core, introduces src/libsVito Caputo
This is the first step of breaking out all the core rendering stuffs into reusable libraries and making modules purely compositional, consumers of various included rendering/effects libraries. Expect multiple modules leveraging libray for a variety of scenes and such. Also expect compositions mixing the various libraries for more interesting visuals.
2018-02-28ray: implement distance-based light brightnessVito Caputo
2018-02-27util: add windows flavor of get_ncpus()Vito Caputo
2018-02-27*: make buildable for windows w/mingw32Vito Caputo
strndup is missing, add trivial implementation signals are missing so fps counter is disabled for now
2018-02-27build: make drm optionalChristian Hergert
2018-02-27autotools: remove vestigial ROTOTILLER_* varsVito Caputo
Fixes silly cosmetic error in configure output for checking libdrm...
2018-02-26sdl_fb: add fullscreen= and size= settingsVito Caputo
fullscreen takes either "on" or "off" size expects WxH arguments, defaults still to 640x480 size is optional when fullscreen=on. Through the setup machinery, when fullscreen has been selected it will not ask for a size - a "fullscreen desktop" mode is presumed. However, thorugh the explicit commandline flags, a mixed mode can be achieved by specifying both "fullscreen=on,size=WxH". This instructs SDL to attempt a video mode switch to the specified size if needed. I've found it to be pretty unreliable on my Xorg/linux system, unless I choose the same video mode as my desktop is already in. Then I get what looks like rendering into the root window or something, it's weird. Hence there's no effort made to expose that in the interactive setup, but it's technically possible and some effort was made to wire it up.
2018-02-26sdl_fb: jump through SDL_Main() hoopsVito Caputo
Since I don't use the SDL event loop, this needs to be done to keep things happy apparently.
2018-02-26sdl_fb: drain event queue on page flipVito Caputo
2018-02-26threads: fix cancellation on destroyVito Caputo
Depending on where cancellation was happening, locks were potentially left held which could result in the next thread being cancelled deadlocking. In deferred cancellation, only cancellation points realize the cancellation. So one worker thread could realize the cancellation entering say, pthread_cond_wait, and exit with the associated mutex still held. The other thread could be in the process of returning from pthread_cond_wait - past the cancellation point already, and get stuck in trying to acquire the mutex as pthread_cond_wait does before returning, because the lock was left held by the other thread. Instead, use the cleanup handlers to unlock the mutexes, and enable asynchronous cancellation. This seems to eliminate the observed occasional deadlocks on destroy.
2018-02-26rototiller,fb: swap dispatch with page flippingVito Caputo
For the sake of sdl_fb, move page flipping into the main thread and run module render dispatch from another thread instead. This eliminates the fb flipper thread, moving its functionality into fb_flip() which synchronously consumes and performs a single flip from the same queue as before - the function is verbatim the loop body of the flipper thread. Now main() calls fb_flip() in a loop where it previously dispatched pages for rendering. Rendering dispatch is now performed in a created thread. See the comment in fb.c for more explanation of this shuffle.
2018-02-23drm_fb,sdl_fb: drop vestigial headersVito Caputo
With fb backends entirely abstracted behind fb_ops_t, this is no longer necessary.
2018-02-23rototiller: drop vestigial drm includesVito Caputo
2018-02-23util: drop stdio ask_$type() helpersVito Caputo
With drmsetup.c gone these are no longer used and I don't see their use returning. Get rid of them.
2018-02-22fb,settings,drm_fb,sd_fb: const settings_t readersVito Caputo
The fb_ops entrypoints and their descendants are purely readers of the settings, so constify their settings_t instances and the operative functions which only read settings.
2018-02-22rototiller: make the sdl video backend the defaultVito Caputo
Since people are more likely to first run this from a GUI environment, default to SDL which should work in most situations. Then if they want they can switch to a linux console and explicitly use the drm video backend.
2018-02-22rototiller: wire up sdl video backendVito Caputo
2018-02-22sdl_fb: implement rudimentary sdl fb backendVito Caputo
This uses a simple fixed 640x480 windowed mode (for now). The SDL2 Renderer & Texture API is used for vsync-synchronized presents. There's probably excessive copying going on because the rototiller fb code manages pages and flips but SDL2 doesn't really expose low-level control of such things. This backend is quite useful for development purposes, allowing quick iteration in a windowed environment. Note this is just the backend implementation, it's dormant code but trivially activated.
2018-02-22*: embrace new generic settings paradigmVito Caputo
This should probably be split into multiple commits, but for simplicity sake it's all cut over at once. drm_fb.c sees major changes, migrating the remaining drm-specific bits from drmsetup into it, behind the settings API. rototiller.c sees a bunch of scaffolding surrounding the settings API and wiring it up into the commandline handling and renderers and video backends. fb.[ch] see minor changes as settings get plumbed to the backend drmsetup.[ch] goes bye bye
2018-02-20setup: add simple stdio setup_interactively()Vito Caputo
Preliminary means for interactively configuring settings and defaults
2018-02-20rototiller: rudimentary argv parsing scaffoldingVito Caputo
Nothing wired up yet.
2018-02-20settings: introduce abstract settingsVito Caputo
Settings will be used to express configurable parameters in the rendering modules and fb backends. The goal is to address both commandline argument setting of parameters, automatic use of defaults, as well as interactive configuration including the outputting of the resulting settings in a form usable as a commandline for future reuse. Since settings can be numerous and highly varied from one module or backend to another, a form similar to the Linux kernel's cmdline or QEMU's approach has been adopted. For example, a complete DRM backend, card selection and config would be: rototiller --video=drm,dev=/dev/dri/card0,connector=LVDS-1,mode=1024x768@60 If any of the above were omitted, then the missing settings would be interactively configured. If you added --defaults, then any omissions would be automatically filled in with the defaults. i.e. rototiller --video=drm,dev=/dev/dri/card4 --defaults would use the preferred connector and mode for that card. rototiller --video=drm --defaults would do the same but also default to the /dev/dri/card0 path. for brevity, I omitted rendering modules from above, but the same approach applies simply to --module=: rototiller --module=sparkler --video=drm --defaults If you ran rototiller without any arguments, then a fully interactive setup would ensue for module and video. If you ran rototiller with just --defaults, then everything is defaulted for you. A default rendering module will be used (the original roto renderer, probably). Note that this commit only adds scaffolding to make this possible, none of this is wired up yet.
2018-01-01fb: switch over to fb_ops_t abstractionVito Caputo
Remove everything drm-related from fb.c, utilizing the implementation in drm_fb.c instead.
2018-01-01drm_fb: implement drm fb backendVito Caputo
Largely mechanical copying of the drm code into the new fb_ops_t abstraction. Dormant for now.
2018-01-01fb: introduce fb_ops_tVito Caputo
Hooks for fb acquire/release, page allocate, free, and flip. This should encompass everything currently needed for the drm backend, which will move behind this abstraction in a later commit.
2017-12-31fb: combine page flip with waitVito Caputo
Tidying this up a bit in preparation of ripping out all drm-specific stuff from fb.[ch]. Future commits will refactor fb.c to utilize an fb_ops_t for hooks to allocate, flip, and free pages.
2017-12-23ray: constify input scene and camera parametersVito Caputo
also const the ray_euler_t basis
2017-12-23ray: constify all ray_3f_t method parametersVito Caputo
2017-12-23ray: split object render from object descriptionVito Caputo
This moves the per-object _prepared state into ray_render_object_$type structs with all the rendering-related object methods switched to operate on the new render structs. Since the current rendering code just makes all these assumptions about light objects being point lights, I've just dropped all the stuff associated with rendering light objects for now. I think it will be refactored a bit later on when the rendering code stops hard-coding the point light stuff. These changes open up the possibility of constifying the scene and constituent objects, now that rendering doesn't shove the prepared state into the embedded _prepared object substructs.
2017-12-10ray: split scene data from render stateVito Caputo
This introduces ray_render_t, and ray_render.[ch]. The _prepared member of ray_scene_t has been moved to ray_render_t, and the other _prepared members (e.g. objects) will follow. Up until now I've just been sticking the precomputed state under _prepared members of their associated structures, and simply using convention to enforce anything resembling an api boundary. It's been convenient without being inefficient, but I'd like to move the ray code into more of a reusable library and this wart needs to be addressed. The render state is also where any spatial indexes will be built and maintained, another thing I've been experimenting with. Note most of the churn here is just renaming ray_scene.c to ray_render.c. A nearly global s/ray_scene/ray_render/ has occurred, now that ray_scene_t really only serves as glue to bind objects, lights, and scene-global properties into a cohesive unit.
2017-12-10rototiller: introduce module.finish_frame()Vito Caputo
Add a hook for post-render serialized frame completion, some of the renderers may have state to cleanup after rendering a frame. A future commit may change add a return value to control flow for features like multi-pass rendering within a given module. The raytracer for example may want to add concurrently executed post filters, and having a non-void return from finish_frame() would be a tidy way to tell rototiller "go back to prepare->render for this context" as many times as necessary, keeping the pass state in the context. For now its return is void however, as I just need a cleanup hook as the raytracer becomes more stateful per frame with a BIH spatial index in the works.
2017-12-10ray: add module context ray_context_tVito Caputo
Before I can clean up the ray_scene_t._prepared kludge I need a place to keep state from frame prepare to render, enter context. Future commits will migrate the _prepared stuff into a separate ray_render_t which is constructed on prepare then acted on in fragment render. Then spatial acceleration structures may be added, constructed at prepare phase and shared across the concurrent rendering.
© All Rights Reserved