razish / xsngine Goto Github PK

e.g. registering shaders, textures, meshes, materials.

Templated, inherited or handle-based?
std::shared_ptr to indicate ownership? manual ref-count? resources will be shared

need to discern between networked resources and local resource handles, i.e. server may indicate a material is being used on an entity, which correlates to multiple resources on the client?

See https://github.com/shaunlebron/blinky

Input event -> keystate management -> console catcher -> game catcher -> key binds

Should cache them.
Store generated texture atlas and glyph data on disk for each requested size.

At the moment it's using additive blend from gl state, which is wrong.
Noticeable artefact: console background does not show

https://bitbucket.org/alfonse/glloadgen/wiki/Home

background, scroller, clickers/incrementers
could be partially defined by a menu?

Not the Renderer state. the ClientGame should operate on its local data for screen size (think splitscreen)

WRT the fetching of last n lines.
Will have to change storage + interface of MessageBuffer

Konstantin Käfer
Valve @ SIGGRAPH 2007
libgdx wiki
Wolfire blog
GLyphy talk

Also consider HarfBuzz? and/or Uniscribe for Windows?

Apparently this doesn't work well for crisp fonts and sub-pixel rendering.

Depends on #30 and #28

Probably not worth keeping current branch.
Use it for reference, and research Forward+ with alpha/translucency support.

Add fog, research different techniques and expose multiple options. Work out where to apply the fog to WRT code.

initially just lerp, then slerp and other methods later on
optimise server update rate

Depends on #30

Views should not own FBOs as they're a limited resource.
When an FBO is required, the view should request a valid FBO (creating one if necessary) and lock it when it's in use/should not be modified.

Just to get some 3d content in to work on scene camera (#15) and such

At the moment, mouse movements when the console is active still affects the game's viewAngles.

so View::renderObjects and View::pointLights, does it make sense to have them as queues?
actually, yeah. so it looks like the View represents the scene as well as stores the render commands
i think having a separate class (a Scene class?) should represent the scene, and that way you're able to have multiple views (think cameras) into the same scene
e.g. for in-game camera/portal, multiplayer split screen, etc etc
so you would have a retained renderer rather than immediate. and this would be reflected in your client game module as well
having a scene class also makes sense for rendering shadows. you may want to render from a specific view, but this doesn't include all of the entities you would need to render correct shadows (off-screen entities may contribute to shadows seen on-screen)

I guess so =]

Improved upon by #33

Define order of collision tests in order of average performance cost

http://herbsutter.com/gotw/_100/

http://accu.org/index.php/journals/269

Separating renderer frontend/backend

ala iD tech 3?

summons @xycaleth
Any examples/resources :D?

Introduced by reliable/unreliable, buffering, state interpolation on client (+ TODO: slerp)

resorting to glVertexAttribPointer + glDrawArrays

Depends on #36

Abstract the OS path from the game path to clean up file I/O

Could simply use <com_path>/ for now.

TODO: Enforce no read/write outside of game directory, including directory traversal
TODO: Enforce lower-case paths?
TODO: Enforce '/' as only path separator - convert '' to '/'
TODO: Touch( 'file' );

virtual functions for Init/Bind/Register, Restart, Shutdown
Modular in libraries? i.e. video, client, etc.

Not really necessary to enforce. Probably best to just follow suit.

thought about passing it via scons based on if 'NO_SSE' in os.environ, but we must also detect if SSE is even supported on this architecture (which won't be the case for ARM, for example)

Depends on #36

Mostly for libpng 1.6 on Linux

Append text to command buffer at various points in code, execute buffer at key points (init, before client/server frames, etc)

Queue multiple commands? delay/wait controls?
Commands are sequential apart from delay/wait controls (will be maintained in separate buffers)

Cvars shall be accessed via set key value i.e. via a command, not implicitly

stdin, console input, and keybinds (i.e. triggered by code) can append text to the buffer.

doesn't properly use w component

[Server/Client]Game/XSCommon should feed Renderer all vert/normal/st info instead of other way around

The two links in the README of "related" repositories are broken.

2D - use stb_image?

• PNG using libpng
• JPEG using libjpeg(-turbo?)
• WebP
• TGA
• BMP
• DDS

3D

• XMF - have to write python import/export tools for Blender.
  xsngine-tools contains obj2xmf and scale_xmf scripts but do not yet compute normals or read out UVs correctly due to format inconsistencies.
  Must drastically improve format (needs separate issue)
• FBX? or keep to tools?

Depends on #37

specify:

• Sampler binding info containing texture path and uniform name.
• Shader programs to use (e.g. vertexShader blah)
• Material flags like wireframe

Need to research shader design, e.g. generic shaders like light_all.glsl and how the switch to deferred rendering will affect this

Introduce the concept of the client being connected to the server and in a "game"

Depends on #30

Further allows: HDR lighting, bloom, depth of field, edge detection

Could be useful to support several, and look at designing an inherited API.

Candidates:

• NBT (Named Binary Tag) [1] [2]
• JSON (JavaScript Object Notation) [1]
• YAML (YAML Ain't Markup Language) [1]
• XML + Schema (eXtensible Markup Language) [1] [[2]](https://en.wikipedia.org/wiki/XML_Schema_(W3C)
• Protocol Buffers [1]
• INI

Do we really just need a generic hierarchical key/value store API?

Preferrably PNG, maybe JPEG.
Depends what image formats we're going to support in general.

should use Markdown