Test representations of floats working*

The boat is floating for now, we just need to make sure it doesn't sink.

BitsToReal and BitsFromReal are consistent with each other...

*Actually looking at the results, for <5,10> vs IEEE half precision... something is wrong
 The plot still looks float-ish though.

Yeah it's broken

Change float representations to be more IEEE-ish

Implemented BitsToReal WRONGLY for like 6 hours.
It's probably still wrong. It works for 8 bit (2,5) floats but probably only because I got lucky.

I am a bit shit at bit shifting.

Tester for exploring the mapping of a float to a real

To visualise the mapping and how you get the trade off between precision and range.

Use low precision, custom, float representations.
Convert via memcpy(3) and copious bit shifting to a Real

Even though Real is actually also a float (default double) at the moment, it's good enough to treat as being an exact representation
when the custom float is 8 bits. Besides, gnuplot can only plot within double precision anyway.

I say "custom" because I have an explicit sign bit for the exponent, which itself is unsigned.
I *think* standard representations have the exponent be a signed int so the sign bit is implied.
Not sure why the mantissa is treated as being unsigned with an explicit sign bit but the exponent isn't?

HFPA says the exponent is between e_min and e_max which is a bit confusing. Is e_min != -e_max normally?

Will do some plots and experiment a bit after sleep.

Tester based on Handbook of Floating-Point Arithmetic 1.1

See also ipdf/documents

Hideously useless buffer perf optimization.

Fix Makefile

The $(BIN) target needed to include the dependencies for header files included via main.cpp

Horrible debug font bufferification. (Sorry)

Don't re-render the display if nothing has changed

We now render to an offscreen buffer, and blit that
to the screen. This probably breaks the bitmap stuff, and I'll
fix that soon.

Slightly less broken GraphicsBuffer implementation.

I copied the original out of some terrible code I'd
written ages ago. It now is less overtly broken.

I'd still like to do an optimized version with Persistant
Mapped Buffers and manual memory control, but that can wait
until post-shaderification.

Real that uses Fast2Sum for addition

I have a feeling this isn't going to improve things at all.

Ability to define Real as long double

`make DEF=-DREAL=2` to compile using long double as Real

Also changed calculatepi to include long double.
And also, only actually integrate using Real if it is something other than float, double, long double.

Remove DebugDumpObjects call

You almost crashed my gedit embedded terminal plugin!

Store everything in a VBO, making things faster.

Also 1024*1024 grid of boxes, for extreme slowness. Yay!

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Conflicts:
src/Makefile
src/main.h
src/real.h
src/screen.cpp
src/view.h

This was one hell of a merge. I have more code coming, but
it breaks other things, so it'll take a little while.

Support doing coordinate transforms on the CPU

So because OpenGL (by default at least), does everything with
32-bit IEEE floats, even when our "Real" type is a double, we lost
precision when rendering it.

This commit adds support for running the coordinate transform on the
CPU using the Real datatype, and only truncating the results, making
things work properly with doubles. This will be slower on documents
with a large number of objects, but there's no real difference in
our unoptimized code at the moment.

Right-click to switch between CPU and GPU transforms.

Hacky debug font system, performance counter.

Allow setting type of Real at compilation time

Use a REAL preprocessor definition.
Pass it from the Makefile in variable DEF

Can change using `make DEF=REAL=X`

Also allowed changing bounds with arguments in main.
Probably not that useful. Might remove later.

Tried to make a tester that overlays a series of BMPs but
the RenderBMP -> ScreenShot approach only works once; subsequent attempts lead to entirely filled images.

Merge branch 'master' of git.ucc.asn.au:/ipdf/code

Conflicts:
src/screen.cpp

David's way is better.

Fix Screen::ScreenShot

Something to do with the OpenGL buffers meant that the rendered BMP wasn't in the buffer before the glReadPixels call.

I have no idea why the screenshot worked for the rectangles and not for a texture, but oh well.

Bunch-a-bugfixes!

- Screenshots work properly.
- Alpha works properly
- New screen clear function, so we don't throw away things we need.

Fix colour in ScreenShot

GL_RGBA -> GL_BGRA

Although... should probably have a means to detect which it is supposed to be
since it might be different on other machines?

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Can render a BMP but things are still going wrong

If Screen::RenderBMP is called before Screen::ScreenShot, the resulting BMP is blank.

NOTE: Testing colours: If -c 1 0 0 1 is passed, rectangle is rendered RED.
However, if Screen::ScreenShot is called, the rectangle is BLUE.

Something stupid going on with colours?
Tried messing with alpha channel, but things seem to always render regardless of their alpha value.

Should give up and do something actually important.

Implement Pointless Broken Things

Trying to overlay the screenshot on an existing bmp to make it easier to combine the outputs of
different implementations (ie: Recompile program with a different typedef instead of using templates).

Rendering the existing bmp is proving to be a pain.

This is also using ancient opengl.

Cannot see what is wrong. I get something in the window but it does not resemble the bmp I saved at all.
And then the screenshot of *that* is just totally black.

Add grid lines

It seemed like a good idea at the time.

Screenshot using glReadPixels instead

Which SDL2 is calling underneath somewhere in that "SDL_RenderReadPixels" call.

Screenshot using convoluted SDL2 approach

David has just told me I should have used glReadPixels
Stay tuned for another commit.

Actual fix for when `uname -i` doesn't work

Just use `uname -m`

Reflect fixes to I/O in ipdf/vfpu

Commits in ipdf/vfpu:
 354bf006d86abdfad9dbb915facec36f99af77bc
 e005897cffaf46cbbed14b3cc1ef74a390c93fef

Only using 1 hex character for opcode (3 bits) and rmode (2 bits) as opposed to 1 char per bit (...)
Also no need to print extra newline; it was a bug in ipdf/vfpu

Remove REAL_HALF as it doesn't actually implement a half precision float

More to it than just masking bits because the sizes of the exponent differ.
Could just mask bits in the mantissa but I have horrible plans involving VFPU...

Allow VFPU to save output vcd file

That was amazingly simple.
Can run `gtkwave` on the output vcd file to see all the signals!

Modify symlinks

Using a symlink to a symlink... I don't know why. Because I can.

Add rounding mode to VFPU

For some reason it needs an extra newline?
It would be much better if this used binary read/write.

Will look into getting that to happen in the ipdf/vfpu repo at some point.

VFPU now using std::bitset instead of just float typedef

It's still 32 bits. However it might not break if I change it?
Can't test it at the moment because the virtual FPU is 32 bits still.

An interface for a FPU compiled from VHDL

I have tested with the FPU from https://github.com/jop-devel/jop

The way this works is really awful...

1. Make (or steal from jop) a VHDL FPU
2. Make (or steal from jop) a testbench that uses stdio to read operands and ops
   - The jop one reads from a generated file, but it is trivial to change to "STD_INPUT" and remove all the assertion tests.
3. Compile testbench into an executable with ghdl
4. Call VFPU::Start which does the following:
   - Create a socketpair(2)
   - fork(2) and in the child dup(2) stdin/stdout to the socketpair
     - Redirect stderr to /dev/null because the testbench generates 10^3 warning messages
   - in the child, exec(3) the testbench FPU
5. Call VFPU::Exec passing the desired operands and opcodes
   - The operands and opcodes are written as hex strings over the socketpair
   - The child executing the FPU program does its thing
   - The result is read back as a hex string
6. When finished, call VFPU::Halt to kill(2) the FPU

I tried to get ghdl and gcc/g++ to make a static library to call ghdl_main instead
of exec'ing things. But that didn't work. The fork and socketpair would have still been
required for that approach anyway.

TODO:
  - Make the interface (not the FPU) deal with arbitrary size registers
  - Wrap a Real type around it so we can #define REAL_SIMULATED_FPU

I haven't put any of the VHDL in the git repo for obvious reasons.
If I actually start messing with it, it will probably get a seperate repo.

This may end up being a complete waste of time?
Although potentially being able to run an arbitrary FPU albeit in a horrible manner does seem cool.

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Fix RealToFloat test (hopefully)

Use x86_64 when uname is broken

Wierd...

>> sam@daedalus:~$ uname -i
>> unknown
>> sam@daedalus:~$ uname -a
>> Linux daedalus 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux

Zoom in and out with the mouse wheel.

Note that zoom-out is totally broken with half-precision,
so single-precision is the default. You can still see some artefacts
in single precision mode if you zoom in enough.

Zoom into the corner of a rectangle and then click on the corner an try to drag it.
Eventually you'll notice the reduced precision, and the rectangle will jump around.

Don't get Filled and Outline the wrong way around.

You can move around a document with Click+Drag!

Uses some scary C++11 features, so no idea if this will break the CS Lab machines
and their ancient version of gcc.

It works on the lab machines now, I swear.

Magic SDL2 sauce! Now with 32-bit!

(My deepest and most sincere apologies to anyone who tries to read the Makefile now)

David's secret SDL2 magic sauce!

Add tester for numerical calculation of PI

Calculate PI using float, double and Real and compare the error and performance.

Traditional floats have a point (hardware dependent) where the error starts to behave unpredictably
rather than decreasing with number of intervals - due to rounding/precision errors.
Can see that doubles are better than single precision floats but they still do it.

An infinite precision Real would not have these problems (hah!)
We can at least aim to do better than double.

Based on PHYS CQM/pprog courses from 2012.
Should probably find a literature reference for this.

Save/Load chunks.

Tester to compare custom Real to IEEE float

Also got the endianness right this time. I think.

Make real.h so we can change reals

Needed to fix view.cpp to call Float where it expects GLfloat
Had an attempt at making a half precision float, but it didn't go very well.

I don't think half precision floats are *that* terrible...
Probably got the bit masking wrong.

Merge branch 'master' of git.ucc.asn.au:/ipdf/code

Conflicts:
src/main.cpp

Fixed that and also fixed other things.

Tweak Makefile to make testing nicer

Who said you needed fancy high level languages to do unit testing?

It can't just be done using Make though; a bash script was also needed.

Crazy std::vector<T> loader and saver.

CMake support. We don't have to use it, but it's there if we do.

It now is all the working.

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Add ObjectType for Object Type

Initial outline rendering.

Implement document saving and loading

Also implemented a tester to test it doesn't explode.

We should set this up to make replacing main() easy.

All of the SDL2 graphics stuff.

(With deprecated, obsolete OpenGL functions! Woo!)

Fix makefile.

Added Document and View classes

And member functions for doing stuff.

Document Format completed (not really).

ipdf.h and Real type

Real == float for now. Can make a class and overload it later.

Naming convention:

void ThisIsAFunction(Type this_is_a_var);

Some makefile changes

Add basic code

Log functions & Makefil

The code repository exists....?