Barbitoric and Buggy Boy demos on youtube

Want to discuss about Demos on the Oric, here you are !
Post Reply
User avatar
Dbug
Site Admin
Posts: 3456
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Barbitoric and Buggy Boy demos on youtube

Post by Dbug »

The quality is crappy, but at least it allows people who never manage to setup an Oric emulator to see an Oric demo:

Barbitoric:
http://youtube.com/watch?v=slHKp9eeosE

Buggy Boy:
http://www.youtube.com/v/Rp1WBfoDWpY

Spocky
2nd Star Corporal
Posts: 28
Joined: Sun Nov 18, 2012 10:56 am
Location: Melun (France)

Re: Barbitoric and Buggy Boy demos on youtube

Post by Spocky »

Hello everyone,

this post is in particular for all people who made the Barbitoric demo.

I have begin some little demo effect but when I see the lot of demo and in particular Barbitoric, I don't understand how to make some effect. In fact, I don't understand how the oric can make It so fluently. In particular the duck, the vinyle and the plasma (Dbug call it).

I have search in defence-force and the forum but I haven't seen any line code or explanation about it.

So my question: can I have some part of the code use or some explanation about the function used to managed the effect?

I know a code could be really personnal and secrect so if it's the cas I will try to manage it by myself :wink:

User avatar
Dbug
Site Admin
Posts: 3456
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Barbitoric and Buggy Boy demos on youtube

Post by Dbug »

Spocky wrote:In particular the duck, the vinyle and the plasma (Dbug call it).
The duck was very simple: It's just an animated sequence of the 3D Studio duck saved as pictures and then converted and compressed with FilePack. Then they are decompressed in the redefined character set area. The screen contains sequences of ABCDEF...ABCDEF...ABCDEF.... so the duck appears duplicated on the screen :)

The turn table was much more difficult to make, I had to generate code for each pixel to either plot or erase a pixel, so technically it's a large table of AND/OR/STA.

The plasma is a tricked out fire effect. At least one version was like that, don't remember exactly how it was done. The display is using the TEXT mode with HIRES rasters to generate the many colors.

Spocky wrote:I have search in defence-force and the forum but I haven't seen any line code or explanation about it.
So my question: can I have some part of the code use or some explanation about the function used to managed the effect?
I know a code could be really personal and secret so if it's the case I will try to manage it by myself :wink:
I have to see if I have the code of all of it, if I can find it I can post it on the svn server, but I'm in holidays right now and don't have access to the source code so this will have to wait for 2013 :)

About the secrecy, well, we already have a bunch of stuff available publicly:
- http://miniserve.defence-force.org/svn/public/oric/
- http://miniserve.defence-force.org/svn/ ... bug/demos/

Spocky
2nd Star Corporal
Posts: 28
Joined: Sun Nov 18, 2012 10:56 am
Location: Melun (France)

Re: Barbitoric and Buggy Boy demos on youtube

Post by Spocky »

Thanks for the answers.

I've looked quickly the svn files. Their a lot of interesting things on it.

The first things I want to try, is to use the duck effect. But when I looked the description of FilePack and memcpy (<= seems to be the function use to display picture as the hires_picture from OSDK shows) I don't understand how do you make it in small area. In fact, if I understand well what you meen, you use only one duck moving for all. For me the tricks would be more easy to use a picture for every frame in fact so with all the duck.

So it's the first (in this case if I can have more detail :mrgreen: ) or the second?

For the source code, It's not important now. with the links you provide me, I have lot of things to look at :wink:

User avatar
Dbug
Site Admin
Posts: 3456
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Barbitoric and Buggy Boy demos on youtube

Post by Dbug »

If you try to compress all the ducks, you will run into two problems:
1) This will use much more memory
2) You will have to refresh a full HIRES screen, each frame, which is very slow

The effect with the ducks is not in HIRES, it's in TEXT.

The pictures are not decompressed in the video memory, they are decompressed in the redefinable character set area.
Just think of the ducks as large sprites drawn with multiple characters:
ABCDEF
GHIJKLM
NOPQRS

If you poke values at #B400+65*8 you will change the way the A character looks like.
Look there for more details: http://www.defence-force.org/computing/ ... /index.htm

In Barbitoric the fullscreen distorter effect (Mashmallows) with the repeating patterns is done exactly the same way. It's TEXT mode, not HIRES.

Spocky
2nd Star Corporal
Posts: 28
Joined: Sun Nov 18, 2012 10:56 am
Location: Melun (France)

Re: Barbitoric and Buggy Boy demos on youtube

Post by Spocky »

Ok!

It's really an intersting method.

So when you change in memory the character, it also change on the screen and you don't have to reprint them in fact. I will try to do this.

I will try to do something like this :P

bigbudd
Private
Posts: 2
Joined: Thu Feb 14, 2013 7:44 am
Location: Middlesex, UK

Re: Barbitoric and Buggy Boy demos on youtube

Post by bigbudd »

Oric ahahahahahahahahahahahahahahahahahahaha


Atari 2600 can run better forum than this

User avatar
Dbug
Site Admin
Posts: 3456
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Barbitoric and Buggy Boy demos on youtube

Post by Dbug »

bigbudd wrote:Oric ahahahahahahahahahahahahahahahahahahaha
Atari 2600 can run better forum than this
Actually no it cannot, it does not have enough memory to store the content of your message, as an example.
Also a single smiley would be displayed almost full-screen due to the limited resolution.

Jylam
Private
Posts: 3
Joined: Mon Jan 09, 2006 1:49 pm
Location: Paris, France
Contact:

Re: Barbitoric and Buggy Boy demos on youtube

Post by Jylam »

Dbug wrote:
Thu Dec 27, 2012 8:26 pm
Spocky wrote:In particular the duck, the vinyle and the plasma (Dbug call it).
The plasma is a tricked out fire effect. At least one version was like that, don't remember exactly how it was done. The display is using the TEXT mode with HIRES rasters to generate the many colors.
As I seem to recall (it's been 18 years (!!!)), I wrote the plasma. You can imagine the effect as two images such as Image and another one similar but a bit different, based on a cos(t*C+x) and sin(t*C+y) or whatever. Add the two images, clamp the result, and update t for the next frame.
Of course you can't store the two images, so everything is based on some precomputed sin/cos table(s), but basically you get a pixel for two memory read, an addition and a clamp (or a test or whatnot, my memory is not that good anymore).
The graphic mode is the wonderful RGB mode that DBug devised during the last century (he is very old).

For all intents and purposes, it is basically the same graphical effect as the metaballs in the same demo.

ThomH
Flying Officer
Posts: 222
Joined: Thu Oct 13, 2016 9:55 pm

Re: Barbitoric and Buggy Boy demos on youtube

Post by ThomH »

By luck, I happen to have once implemented it in GLSL for the sake of a StackOverflow answer, which means I can immediately provide the lookup-free per-pixel code:

Code: Select all

void main()
{
	/*
		Each sheet is coloured individually to look like ripples on
		the surface of a pond after a stone has been thrown in. So it's
		a sine function on distance from the centre. We adjust the ripple
		size with a quick multiplier.
		Rule of thumb: bigger multiplier = smaller details on screen.
	*/
	mediump vec3 distances =
		vec3(
			sin(length(texCoordVarying1) * 18.0),
			sin(length(texCoordVarying2) * 14.2),
			sin(length(texCoordVarying3) * 11.9)
		);

	/*
		We work out outputColour in the range 0.0 to 1.0 by adding them,
		and using the sine of that.
	*/
	mediump float outputColour = 0.5 + sin(dot(distances, vec3(1.0, 1.0, 1.0)))*0.5;

	/*
		Finally the fragment colour is created by linearly interpolating
		in the range of the selected start and end colours 48 36 208
	*/
	gl_FragColor =
		mix( vec4(0.37, 0.5, 1.0, 1.0), vec4(0.17, 0.1, 0.8, 1.0), outputColour);
}
The only context you need is that texCoordVarying1, 2 and 3 are 2d vectors each representing a normal aligned 2d rectangle — so counting (x, y) in pixels, essentially — relative to three of those ripple patterns. Then the rest is: (i) compute distances from centres; (ii) sum sine values; (iii) use that value to interpolate between two colours.

So that's exactly as described by Jylam if adapted to an 8-bit CPU: ideally a 2d lookup for intensity (often these things are at character resolution, not pixel, with dithered output partly to disguise the fact but mainly for better colours, so the tables are a few kilobytes), but failing that a combination of [smaller] distance and sine table lookups, summation and clamping of the results, and then a mapping to output colour. On some micros you might get the last bit for free depending on how the palette works.

Respective constants aren't necessarily well chosen, but: in video.

Post Reply