If you can get your hands on a 3DFX Voodoo card it would be awesome to test it on Glide!

I've tried launching the PS2 version of this demo using uLaunchELF on my PAL PS2 slim, and it seems to work without any issues.

It might be worth adding that the PS2 demo was tested on real hardware as well. I can provide photos of it running as well if there's interest.

https://github.com/kosua20/herebedragons/tree/master/cycles first word is cyles

Hi,
a version for the Godot Engine 3.0 would be nice as soon as at least a beta is released. :)
I might do a pull request then.

Typo in Readme for section title "Resources"

Maybe I go into a wrong place. :P

Soryy for that - -

May need to update to adopt Xcode 9

Hello!

I was wondering if there are dragons in python too.
I found none, so I had to add them.

herebedragons-python

I'm adding this as an issue mostly because I want to do it but I can't commit any time to it yet or rather can't predict when I'll find some time to do it.

However, it should be a good exercise for anyone.

DirectXTK: https://github.com/Microsoft/DirectXTK

Some future ideas for more optimal circumstances on PS2:

• The PS2 GPU memory is fast enough to flush and refill textures multiple times per frame, according to the developers of Metal Gear Solid 2 - who had up to 10MB of textures on-screen at times inside the 4MB VRAM (total, not including memory used for buffers). It may be possible to use similar techniques to achieve better results in this demo.
• I feel better looking textures could be used with the above method and storing these in the main 32MB RAM and sending them to the GPU as needed - the PS2 has a 3.6GB/s memory bus so the potential is undoubtedly there.
• Using recent gsKit tools available on github may also give the code some cleaner syntax and possibly expand the available libraries?
• Different video modes; I would say that a 640x448i mode and a 640x480p mode would be optimal, however 640x540 at 1080i would also be very interesting - a few games used this for a 1080i mode, and this could look great on HDTVs possibly with antialiasing.

Keep this project up, though. It's nice to see demos like this arise on the PS2. I recommend you check out the gsKit "hi-res" sample code for an idea of what you might be able to do - this seems like a relatively simple scene, and one programmer was able to get a rotating 3D teapot running at native 1920x1080, a 1920x1080 background texture and all with antialiasing at 60FPS. Would be cool to see some improvements here from code like that.

I'll be happy to send in a PR for this.

There's a few, um, less than best practices in the WebGL code. I didn't look at the others

2 examples

• looking up uniform and attribute locations every frame at render time instead of once at init time

• assigning properties to WebGLObjects that could be null

There's also questionable issues like forcing 800x600. That might make sense on desktop PCs where you'd be hard pressed to find a display that's only 800x600 but it makes far less sense on a browser that might be viewed in a phone where the phone is trying to emulate 320x568 resolution.

Another is using devicePixelRatio. Does that happen on your c++ version? In other words if you open an 800x600 window are you getting 800x600 pixels or 800x600 * devicePixelRatio

Other random stuff

Setting the size of the canvas directly is kind of an anti-pattern. You should let CSS choose the size on the web.

Vertex Buffer Objects are available pretty much universally on WebGL

http://webglstats.com/webgl/extension/OES_vertex_array_object?platforms=0000dfffcfbfabfd01

In fact it's only IE and Edge that, not the actual hardware so if you want to use them you can either just use them and tell IE and Edge users they're S.O.L. or you can use polyfill that will just fill it in on IE and EDGE.

Would you be interested in a PR that deals with those issues?