pouët.net

very good! do you have direct frame buffer access or some sort of render to texture functionality ? Or you are avoiding KGL altogether ?

Direct frame buffer access on these effects.

...how ? I though accessing the fb directly was slow (or even copy it to main memory) .

And how did you get the pointer to it ?

@virgill: WOW! I love it :D

I'm working on a demo for a virtual machine i designed. But as you can see its buggy as fuck.

near 300 metaballs physic engine.

WIP shots from particanomaly:
(wrong window title)



Approximating SDFs:

drag & drop preset manager and gm.dls support. also, it's the mercury-synth.

THIS IS NOT NORMAL. BUT ON MATH IT IS.

Red: Holy FSCK. That looks like a real synth, unlike most scene audio products... built for the musician, not for coder? :) (I'm interested in that)

wip : writing an exporter for blender, still some bugs to iron out :



p.s: oh. is it loooooooooooooooooonnnnnnnnnggggg NO U AUTO-RESIZE ?

oh wait. it DID resize!

Here is some basic analytical raytracing (with wrong reflections :P) in background.
And impostors with raytraced balls in foreground.
Planned a 64k for non existing 64k at Assembly. Maybe a next demoparty.

And here is what I managed so far with first look at OpenGL ES 2 in GCW Zero, after some party coding and horrors setting up the toolchain in Linux 64bit and Vista later.

I am testing the shaders btw, one sphere raytracing (with analytical, not distance fields, much faster) and classic floor mapping. Goes fast so far. You could do simple smooth things with the shaders. But sin/cos, abs and length(vec2/3) doesn't work properly because they are still rewriting the drivers, hehe.

Me so fucking lame.

mudlord: once you stop thinking you are so lame, you stop being lame! [/proTipp]

here comes my lameness of today:

Managed to get five(!) 24x32 sprites running in one frame on a stock QL:



Let's just say the machine wasn't exactly built for realtime graphics.

Wow QL? I'd like to see a proper QL demo.

So, what are the disadvantages? I know it has 68000, but the graphics are bitplane or chunky? Some slow videoram? Something else?

I can't discuss all the problems in such small space, but for a start:

- The 68008 sits on an 8-bit bus which cripples it down really badly
- The second possible location for a gfx page is filled with system datas
- Interrupt vectors are in ROM so you can't take over the system and still have a VBI
- There's no real sound chip. The coprocessor, an Intel 8049 can play some weird one-channel sound using its absurd ROM routines
- You can't even reprogram the 8049 because it just runs its ROM code
- Communication with the 8049 bogs down the main CPU, and is required for sound
- Trashy microdrives eating the precious cassettes (luckily have an SD reader now)
- With an unrolled movem loop the QL can almost clear 1/3 of its screen per frame of 32k
- The graphics are kind of linear, except the bits of four consecutive pixels are interleaved in two consecutive bytes - no fast planar tricks here
- There are four bits per pixel, but that doesn't mean 16 colors. One bit was lost for the useless flash attribute (which can't be controlled).
- Fixed 1 bit per component RGB colors
- Pretty much the only tricks available with the gfx hardware are page flipping and blanking, and exact timing is just a dream if the ROM code is running
- No character mode, attribute blocks, sprites, blitter, scrolling or ... anything
- The only viable emulator is a commercial product. You can use a serial cable for uploading your own code but the required plugs are extremely rare.

Wow, that's a lot of ugly stuff.
Good luck coding on that!

Damn, that's gotta be a pain in the butt. Also, good luck! I think even Oric ain't that restrictive.