Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > CSDb Discussions > What is Onefile Demo, what is Graphics...
2017-06-27 18:38
ptoing

Registered: Sep 2005
Posts: 232
What is Onefile Demo, what is Graphics...

I recently started to go through a lot of art on here to put on my SD card for enjoyment on real hardware purposes.

Then I came across Industrial Dawn which is just a picture with music. I don't see anything else going on. (That said, it is really nice, both music and pic).

It is entered as One-File Demo, while a lot of pictures with music (could link a whole bunch by Mermaid for example, but also loads others), which are just entered as Graphics.

I guess there is no super easy way to draw a line here. Any thoughts?

IMO, demo would include at least some kind of effect, or a scroller maybe. But then people had a discussion about this when I released my Headache pic in the gfx compo at X'10.
2017-06-27 19:23
Compyx

Registered: Jan 2005
Posts: 268
Adding anything not required to displaying the graphics would make it a 'demo' in my opinion. So adding music, a scroller would make it a demo. Using a routine just to show the graphics (ie FLI needs a bit of code) is graphics.
2017-06-27 19:57
Groepaz

Registered: Dec 2001
Posts: 8154
i agree :) that'd transform a lot of "graphics" into "demos" :)
2017-06-27 22:32
ptoing

Registered: Sep 2005
Posts: 232
Indeed it would do that.

I guess as soon as you could put it under 2 separate types, ie. music and gfx, it would make a demo.
2017-06-27 22:37
TheRyk

Registered: Mar 2009
Posts: 395
Dejavu... Strictly nitpicking, we'd also move any music which does more than making noise into demo then ;)
2017-06-27 22:41
Groepaz

Registered: Dec 2001
Posts: 8154
actually... i remember back in the days, we called all those things "demos", even if its just a koala :)
2017-06-27 22:42
TheRyk

Registered: Mar 2009
Posts: 395
yeah whatever's not a game

koala = graphic demos :)
2017-06-28 08:36
Jailbird

Registered: Dec 2001
Posts: 1474
This question was brought up about two decades ago, in connection with multi-screen pictures.

IMO, anything that isn't a static image without sound and can't stand on its own as a standstill piece of graphic art (i.e. a coder is more involved than just helping with a simple displayer), is a demo. The same way I'm not too fond of extra graphics or effects added to single music releases (especially on competitions).
2017-06-28 10:55
bugjam

Registered: Apr 2003
Posts: 1256
@JB: regarding gfx in music releases, I reckon most parties solve that problem nowadays by switching the screen off during music compo anyway, so it does not influence the judgement of the tune. And then I do quite enjoy those neat presentations in some tunes, I have to say.
Regarding the topic, I'd concur with ptoing that I'd count gfx + music only as graphics release and whenever an effect is added as onefile demo, but I admit that this discretion is totally arbitrary.
2017-06-28 11:16
ptoing

Registered: Sep 2005
Posts: 232
bugjam: That is not really what I wrote. I can see how a pic with music would be considered a demo. But then I think at X they turned off the music for the pics, not sure though.

They did not however turn off the gfx for the music compo.

Jailbird: So stuff like border sprites and similar things on pictures you would also call demo? I dunno if I would go that far, but I sometimes wonder if separating "pure" modes from "hack" modes, if there are enough entries. But that might be a pain in the ass for the orgas.

Pure as in just Hires or MCOL, hack as in everything else.
2017-06-28 11:41
Sounx

Registered: Dec 2006
Posts: 25
A pic with some music added, but where the clear intention is the release of graphics, is just that... A graphics release. Total nonsense to consider this as onefile demo! Countless 'Logo for XXX' files should be considered onefile demos then. Anything else added but music, like for example scrollers and/or effects, make a onefile demo in my opinion.

A similar situation arises when people use sprites/borders to enhance their graphics. That's what I would surely call a onefile demo as it requires some neat coding and surely the graphics benefit from the added code. Which doesn't make it a standard graphics release anymore.

I find it quite stunning that pictures that use code to work around limitations or polish the pictures with FE. (border)sprites are and have been allowed to participate in 'normal' GFX competitions. It is plain wrong and quite frankly unfair to those graphicians that don't have a coder to back them up.
2017-06-28 12:45
Jailbird

Registered: Dec 2001
Posts: 1474
Quoting Ptoing
Jailbird: So stuff like border sprites and similar things on pictures you would also call demo?

As soon as you think you have to add any additional credits to your graphics release other than "graphics", you should call it a demo. Serious, exclusive programming or musical involvement in a release makes it more than just a single graphics release. I don't think it's too hard to determine when other than pure graphical skills had crucial parts in displaying a screen.
2017-06-28 13:54
ptoing

Registered: Sep 2005
Posts: 232
I can see that point and agree with it.

What about when there is already something out there that easily lets you do stuff, like Timanthes lets you make FLI including the FLI bug area, or I use vicpack to convert Asslace stuff. There was a coder needed to do the original leg work, but same goes for whatever graphics program you use.

So arguably if there was some really powerful editor that would allow flexible sprite overlays, rasters, and border sprites, then what would things made with that fall under?
2017-06-28 20:54
TheRyk

Registered: Mar 2009
Posts: 395
about border sprites making gfx demo: doesn't make sense, as we've got ESCOS aka OSCAR as gfx format.
about "static" artwork only: then all FLI pics wouldn't count as gfx any longer :)

Seriously, I don't think, there is a solution which doesn't create new problems/make things even more complicated
2017-06-28 21:24
Groepaz

Registered: Dec 2001
Posts: 8154
muc more important question is: why do we have "fullscreen graphician" but no "fullscreen graphics"? LAME
2017-06-28 21:24
Tao

Registered: Aug 2002
Posts: 103
Quote: about border sprites making gfx demo: doesn't make sense, as we've got ESCOS aka OSCAR as gfx format.
about "static" artwork only: then all FLI pics wouldn't count as gfx any longer :)

Seriously, I don't think, there is a solution which doesn't create new problems/make things even more complicated


That would fall under "demo maker production" :P
2017-06-28 21:58
ptoing

Registered: Sep 2005
Posts: 232
Quote: muc more important question is: why do we have "fullscreen graphician" but no "fullscreen graphics"? LAME

All those extra graphician options can just go imo. Yes there are people who just made fullscreen mcol and or hires pics, such as DocJM or Wayne Schmidt, and probably some people who also just made logos. But IMO it still is silly.
2017-06-29 01:22
Groepaz

Registered: Dec 2001
Posts: 8154
Quote:
All those extra graphician options can just go

NOOOOOOOOOOOOO
2017-06-29 02:03
soci

Registered: Sep 2003
Posts: 357
If it's runnable it's code and true graphics releases need a separate shower ;)
2017-06-29 02:16
Groepaz

Registered: Dec 2001
Posts: 8154
YOU need a shower perhaps =D (did you mean: viewer? =P)
2017-06-29 08:00
soci

Registered: Sep 2003
Posts: 357
No, I had already and also considered the joke possibility but refrained from using it.

http://csdb.dk/search/?seinsel=all&search=shower

Btw. the list of csdb "professions" is mostly based on disk magazine charts. After all this is an archival site and not another FB.
2017-06-29 12:45
saimo

Registered: Aug 2009
Posts: 35
I guess that the problem lies in the broadness of "graphics" and in the lack of specific categories. To me, "graphics" refers to an exclusively visual product. That automatically puts entries with music in some other category. But then, there is still a problem: what does "graphics" include?
It certainly includes still pictures.
But also a picture with a color cycling effect is a purely graphical product, so does it qualify as "graphics"? I'd say yes (even if I don't like that), because the effect makes it more than just a still picture, but still less than a demo, as the code is just too trivial; on the other hand, a complex real-time twisting/lighting/whatever effect would make it a demo because of substantial weight of the code (although the end product is still graphical only).
Then, there are also animations (sequences of still pictures): can they be considered "graphics"? Yes (although, again, I don't like it), as they are a 100% graphical product.
Finally, for completeness, let's consider also videos streaming from disk or REU: are they graphics? Well, if they come with music, according to what said at the beginning, I'd say no (they're "videos" in the common sense, as in "YouTube videos"); otherwise, they can be considered "graphics" (they're basically sequences of pictures like animations).

Regarding the code required to display still pictures, I think it is not relevant to the categorization: no matter how cool the code is, still the end result is a picture. The code should be taken into account when the product shown is more than just a still picture.

Going back to pictures with music, I can't see a proper place for them: C64 Graphics would exclude the musical component, and C64 Music would exclude the graphical one. These productions are more than pictures, but much less than demos. I can only see them in a category of their own.

Summing it all up, this is how I see it (production: ideal category / current CSDb category):
* still pictures: still picture / C64 Graphics
* still pictures with music: picture+music / C64 Misc.
* pictures with trivial visual effects: dynamic picture / C64 Graphics
* pictures with complex visual effects: dynamic picture / C64 One-File Demo
* pictures with visual effects and music: one-file demo / C64 One-File Demo
* sequences of pictures: animations / C64 Graphics
* sequences of pictures with music: videos / C64 Misc.
2017-06-29 19:11
Compyx

Registered: Jan 2005
Posts: 268
I'd rather keep it simple: use "C64 graphics' for static graphics with only the code required to display the image, including images that use the borders.

For logo's and such, I suppose a simple text like used in many 'music' entries can be acceptable, when using the standard font and no fancy colorcycling.

Images using multiple screens I'm not sure about, I suppose a simple display routine (VSP or linecrunch) can be acceptable, but not when using for example the linecrunch area to display (swinging) logo's etc.

Adding music which will alter the perception of the graphics displayed is a no-no.

Edit: using a cruncher for faster loading of the image + display routine should also be acceptable. Not strictly required to display an image, but makes loading less painful.
2017-06-29 19:54
Groepaz

Registered: Dec 2001
Posts: 8154
guess we also need "dynamic graphician" then!
2017-06-29 20:09
Carrion

Registered: Feb 2009
Posts: 195
guys, guys...
just introduce tags... you know... to tag releases like:
#koala #doublescreen #horizontal #sprites #music

I solved this for you.
thread can be closed now.
thank you!
2017-06-29 21:15
Scan

Registered: Dec 2015
Posts: 49
So that has been settled? Let's carry on...
2017-06-29 21:28
Compyx

Registered: Jan 2005
Posts: 268
Oh no, no way.

Now we need sprite-graphician, which in turn is split into hires-sprite graphician, multi-color-sprite graphician, overlayed sprite graphician (ie 2x SC sprite or 1x MC + 1x SC), combined overlayed sprite graphician (see before).

Then there's the case of using bitmap or charset in combination with those sprite modes I mentioned before. Basically we'll end up with 128+ different categories, both for graphics and for people doing graphics.

And what about coders? To be fair, there should be 1K coders, 4K coders, 16K coders and 'normal' coders, at least.
2017-06-29 21:46
Mermaid

Registered: Jan 2002
Posts: 321
You people have too much time on your hands.
2017-06-29 21:59
Groepaz

Registered: Dec 2001
Posts: 8154
and wouldnt it be appropriate to tag mermaids stuff with #underthesea ?
2017-06-29 22:06
lft

Registered: Jul 2007
Posts: 282
Speaking of semantics: Are interlaced pictures animations?

Sounx makes a good point ("where the clear intention is the release of graphics"). Documenting the intention of the artist adds more information to the database than if the category can be derived from the artefact itself.

If a program was released in a graphics compo, it's a graphics release, even if it also plays a little melody. If the same program was released in a music compo, it's a music release, even if there's a bouncing goblin on the screen. And if --- gasp! --- it was released on csdb, then the intention of the artist is encoded in the choice of category when uploading.
2017-06-29 22:12
ptoing

Registered: Sep 2005
Posts: 232
lft: that is an interesting way to look at it. Valid as well IMO.

As far as interlace being animation goes, I don't think so. In interlaced pictures, the way they traditionally are presented, there is no intent to show animation/movement, but to increase the resolution/colour depth.

IMO a char blinking in 2 colours is not animation, or even blinking in many colours. Is the garbled data written into the screen area you get when loading stuff sometimes animation? Not really. Could it be if used with intent and cleverly. Sure. But as I already stated earlier. This discussion kinda came up over my Headache picture.
2017-06-29 22:12
ptoing

Registered: Sep 2005
Posts: 232
That said, tags would be neat.
2017-06-29 22:43
Groepaz

Registered: Dec 2001
Posts: 8154
#blinkingchars
2017-06-29 23:49
rail slave

Registered: Feb 2016
Posts: 8
couldn't tags be abused though ? well, unless they are public and accountable so people arn't tagging all there pics mermaid,ptoing or whatever :P
2017-06-29 23:52
ptoing

Registered: Sep 2005
Posts: 232
if there was a tag system, there should be some basic first tags, and users should be able to add new tags, and then they have to be approved first, so people can not add dumb shit willy nilly.

But this would be extra work on the staff here. And it would be somewhat involved, so I am not holding my breath.
2017-06-30 00:17
Compyx

Registered: Jan 2005
Posts: 268
Quoting lft
Speaking of semantics: Are interlaced pictures animations?

Yes.

*snip*

Quoting lft
If a program was released in a graphics compo, it's a graphics release, even if it also plays a little melody. If the same program was released in a music compo, it's a music release, even if there's a bouncing goblin on the screen. And if --- gasp! --- it was released on csdb, then the intention of the artist is encoded in the choice of category when uploading.


So people would enter a release in three categories?
2017-06-30 00:25
Groepaz

Registered: Dec 2001
Posts: 8154
ptoing: its exactly how it works like now, except its not called "tags", and rather than having some sort of interface for adding new ones, you ask for something being added.
2017-06-30 00:30
ptoing

Registered: Sep 2005
Posts: 232
I know, I have asked Perff to add stuff before, and he did.
2017-06-30 06:52
lft

Registered: Jul 2007
Posts: 282
Quoting Compyx

So people would enter a release in three categories?


A production would only get released once, presumably, because most compos have rules that disqualify re-releases.

The point is that the category reflects something about the release (the event of releasing a production), and not about the production itself.

What's unclear is how the database should model an event where the same production competes in multiple compos. This is probably rare enough that it could be represented by multiple releases. But consider the X'16 demo compo, which included a one-filer award. How do we label the releases that qualified for both awards? Main intention of the submitter?
2017-06-30 09:14
Jailbird

Registered: Dec 2001
Posts: 1474
Tags? Yeah, sure. You guys are fighting a battle already lost.

I have tried to lobby for them a bunch of times, but eventually gave up. I guess there are more important things to fix/implement on CSDb, a tagging feature would be somewhere on the end of the to-do list.

Here's the tags thread where you could go wild about them:

Tags (yet again)
2017-06-30 09:35
rail slave

Registered: Feb 2016
Posts: 8
Quote: Tags? Yeah, sure. You guys are fighting a battle already lost.

I have tried to lobby for them a bunch of times, but eventually gave up. I guess there are more important things to fix/implement on CSDb, a tagging feature would be somewhere on the end of the to-do list.

Here's the tags thread where you could go wild about them:

Tags (yet again)


Also, some times you want to name your pix some ultra obscure, hipster, 4th wall kind of thing...

not the obvious stuff name, which would get you visibility.

I've kind of resigned to spamming AKA with "tag names"
2017-06-30 12:48
Han

Registered: Apr 2017
Posts: 4
On other systems (i.e. PC) the differentiation is quite simple and could be applied to the C64 as well. At least as a rule for entries at demo parties: Only pure data-files are allowed for the graphics and music-compo. That means the picture or soundfile must be delivered in a well documented format and the organizers define which formats are allowed. On PC that usually means JPG and MP3/MOD.

Those are competitions for graphicians and musicians, so NO proprietary code should be allowed. Every entry should be shown with a viewer/player that is chosen by the organizers and announced in the party invitation.
You discovered a new way to switch the C64 to 16M colors in HD-resolution? Fine, hand it in in the demo competition.
2017-06-30 13:37
lft

Registered: Jul 2007
Posts: 282
That is an interesting and relevant piece of input, especially for people who run compos.

But CSDb is an attempt to document what goes on at demoparties. It's not the other way around. We can't ask compo organisers to do things differently just because it would fit the current database scheme better.

On a side note, I'm not sure that it makes sense to switch from executables to data files for music compos. Once in a while, as an experiment, sure. But, in corpspeak, music compos are driving innovation in playroutine technology. It's fascinating to see what people can make the sid chip do when they have 100% CPU power available.
2017-06-30 14:31
Jailbird

Registered: Dec 2001
Posts: 1474
I'd love to see/compete in a compo where only static native C64 modes are alloved (standard char, hires or multicolor).
2017-06-30 14:51
v3to

Registered: Feb 2005
Posts: 136
Quote: I'd love to see/compete in a compo where only static native C64 modes are alloved (standard char, hires or multicolor).

same here.
2017-06-30 16:17
ptoing

Registered: Sep 2005
Posts: 232
Yeah, I would like that too. I suggested that above. But it would have to be announced in advance, if it was a party. Which should not be a big deal.

If you wanted 2 compos (one for native, one for hacks), you might not get a lot of entries per compo, depending on how big the party is. But in general I would love to see a compo that is just for native formats.
2017-06-30 17:13
Groepaz

Registered: Dec 2001
Posts: 8154
i'd love to SEE such a compo - coz plain hires/multicolor stuff is where the true skills shine. fuck those newfangled hypemodes.
2017-06-30 17:30
TheRyk

Registered: Mar 2009
Posts: 395
pretty much the same here

when I see whatever-FLI gfx, in more than 95% cases I just look at the output and think: "why spooky mode?/why not plain HiRes/MC?"

This applies even for many of the few really good gfx in hanky-panky formats.
2017-06-30 18:06
Carrion

Registered: Feb 2009
Posts: 195
at first my thought was - I'm OK with it too, but then I checked X16 combo entries.
and here it gets interesting...

If only native gfx modes are allowed the results of composition would be:
1. duce - disqualified (sprites)
2. ptoing - disualified (asslace)
3. mermaid - disualified (border sprites)
4. electrin - in
5. yazoo - in
6. leon - out (lace)
7. jok - out (sprites)
8. Aomeba -in
9. Sphnx - in
10. DeeKay - out (NUFLI)
11. booker/wacek - out (NUFLI)
12. lzwerch - uknnown
13. Zillii - in
14. Pal - out (sprites)
15. redback - in
16. Ohli - out
17. grip - in

and I think first 3 (but also others too) are really good images and I feel blessed to see them. with rules discussed above we could probable never see them. or?

I think I'm even more convinced now. everything runnable is OK. but allow to #tag in CSDB.
2017-06-30 18:10
Groepaz

Registered: Dec 2001
Posts: 8154
that logic is flawed. for example there are/were quite some parties/compos who dont allow usage of samples in music compos. did that stop people from doing great sample tunes? clearly not.
2017-06-30 18:22
ptoing

Registered: Sep 2005
Posts: 232
Of course you would have seen them, at least mine. I do not need compos to release images, so pretty much what Groepaz said.
2017-06-30 18:23
Carrion

Registered: Feb 2009
Posts: 195
not convinced here...
the best pictures in last 12 months were released at compos. we dont do these kool pics for demos where we are restricted by coders/rastertime/loadtime etc

we do these pics for competitions. denying it makes you ignorant.
ofcoz I have nothing against pure multicolor/hires/char compos at parties, as Hein suggested.
introduce it slowly to the audience (as JB suggested with tags) or making it another ranking in parallel with normal gfx compo.
2017-06-30 18:25
Carrion

Registered: Feb 2009
Posts: 195
@ptoing.
wrong
you will release them but it's not 100% sure I'll see them. I'm not following all releases at CSDB any more.
But I come here when some important party took place and I want to check who released what, who won, who used new interesting technique...
2017-06-30 18:31
Groepaz

Registered: Dec 2001
Posts: 8154
lol
2017-06-30 18:32
ptoing

Registered: Sep 2005
Posts: 232
I personally make C64 stuff because I like it, and one reason I like it is the different modes that are possible.

If I would do pixelart only because I want to win compos I would do way way less stuff.

If you can't be bothered to do a simple search for latest gfx releases that's on you :P
2017-06-30 18:39
Hein

Registered: Apr 2004
Posts: 800
Quote: not convinced here...
the best pictures in last 12 months were released at compos. we dont do these kool pics for demos where we are restricted by coders/rastertime/loadtime etc

we do these pics for competitions. denying it makes you ignorant.
ofcoz I have nothing against pure multicolor/hires/char compos at parties, as Hein suggested.
introduce it slowly to the audience (as JB suggested with tags) or making it another ranking in parallel with normal gfx compo.


I suggested what? :) I just walked in, minding my own business.
2017-06-30 20:22
Han

Registered: Apr 2017
Posts: 4
Quoting lft
But CSDb is an attempt to document what goes on at demoparties. It's not the other way around. We can't ask compo organisers to do things differently just because it would fit the current database scheme better.

You're right, I just got carried away thinking about that whole subject :)
So to the original question (..put on my SD card for enjoyment on real hardware purposes): for an own collection I wouldn't bother if the release was meant to be a One-filer or whatever. If you like it only for the pictures then put it in the 'graphics' folder.
Here on CSDB there should of course be stated in which category a production was handed in at a demo party.

@all: please note that I did not suggest allowing only static native modes. I wrote 'pure data in a well documented format'. That could also be one that allows border sprites or whatever. The important point is that no coder should be involved.

Apart from this, an own 'Native Mode' compo might make sense, since the technical possibilities of new and native modes differ so vastly. (An 'Oldschool-compo' at a C64-Party.. Sounds weird ;) )
2017-06-30 20:30
ptoing

Registered: Sep 2005
Posts: 232
C64-Oldschool and C64-Newschool, lol.
2017-06-30 22:20
Compyx

Registered: Jan 2005
Posts: 268
I think Hein's post makes the most sense.
2017-06-30 22:31
Groepaz

Registered: Dec 2001
Posts: 8154
and what about middleschool? PAH
2017-06-30 22:52
Hein

Registered: Apr 2004
Posts: 800
May I suggest listening to Bob's wise words about Onefile Demos and Graphics.
2017-06-30 23:04
Groepaz

Registered: Dec 2001
Posts: 8154
what the actual fuck? ^_^
2017-07-02 11:42
xpo

Registered: Mar 2011
Posts: 7
As long as the graphics are the main reason for the release of the product, it will be graphics. I suggest adding two separate categories: "Graphics" for traditional graphic formats (hires, multicolor, fli, ifli, afli, nufli and others) and "Expanded graphics" (for graphics with music, additional sprites, open borders, multiscreens).
2017-07-02 14:34
ptoing

Registered: Sep 2005
Posts: 232
That is a bit of an arbitrary difference. NUFLI has sprites by default for example. Some border stuff like on my WAT or Mermaid's Elsewhere are quite basic, etc.

If you would make the distinction I think going really obvious like pure MCOL and HIRES vs everything else.
2017-07-02 14:58
xpo

Registered: Mar 2011
Posts: 7
By writing "for traditional graphic formats like hires, multicolor, fli, ifli, afli, nufli and others" I meant graphical formats that have normal drawing programs and do not need anything else. In the "expanded graphics" category there will be graphics that require additional code or something like that to create.
2017-07-02 16:28
ptoing

Registered: Sep 2005
Posts: 232
Calling the nufli editor a "normal" drawing program is a bit of a stretch. But I see what you mean. But in the end all it comes down to then is tools, not really format, since someone could make some tool to easier place sprites or have dynamic rasterbars. So this definition would be very flexible and not future proof.
2017-07-02 23:20
Compyx

Registered: Jan 2005
Posts: 268
How about once an editor for a particular 'mode' is released (as Crest did I think), the 'format' is accepted?

Even if that means custom code.
2017-07-03 00:11
Groepaz

Registered: Dec 2001
Posts: 8154
this is not normal method
2017-07-03 08:44
Jailbird

Registered: Dec 2001
Posts: 1474
Haha WTF
2017-07-03 11:59
ChristopherJam

Registered: Aug 2004
Posts: 644
Surely anything that's a static image is graphics, regardless of sprite usage etc?

I'm a little dubious about using "one file demo" for anything that's just a picture plus music.
2017-07-03 14:00
Perplex

Registered: Feb 2009
Posts: 194
Pure graphics means code is not needed to run continuously during display.
2017-07-04 18:01
Compyx

Registered: Jan 2005
Posts: 268
Wouldn't that rule out FLI as a graphics mode?
2017-07-04 18:09
iAN CooG

Registered: May 2002
Posts: 1730
I think that's exactly what Perplex meant. FLI is not "pure" graphic mode, it's more of a demo effect.
2017-07-04 18:25
Compyx

Registered: Jan 2005
Posts: 268
So that would leave: charset (either single-color, multi-color or ECM), bitmap (hires or multi-color) and (max) 8 sprites in whatever configuration you wish.

I suppose adding (max) 8 sprites on top of chars or bitmap would then also be acceptable, since a single setup is needed.

That would leave a lot of formats I consider de facto standards out.

But I think we're never going to agree here. I released 'pure' graphics with my Marvel logo*, and that quickly got a prg version and even the comments shut down.

*) I might have gone a bit overboard with releasing the bitmap, vidram, colram and even the bgcolor separately. But the point was made: people prefer a binary over a raw file. And so do I.
2017-07-04 21:18
xpo

Registered: Mar 2011
Posts: 7
Theres no reason for splitting graphics formats into "pure" and "not-pure". Over the years FLI has become the same standard as MCOL. MCOL, HIRES, FLI, IFLI, MCI and others it's all a classic c64 graphics format.
2017-07-05 15:21
LKP

Registered: Sep 2008
Posts: 5
Demo originates from the word demonstration that in c64 therms is a demonstration for code, graphical or musical skills.
The artist(s) who made his art decides the release type.
If the gfx art demonstration is more important than the music , which may be known from, and used a lot in a game or a demo, he should upload it as c64 graphics.
If the code ,graphics and/or music are equally important it should be uploaded as one file c64 demo and so on..
The artist or at least the uploader decides this and should stay that way. With the credit options he may give credits to other persons, i.e. who did the player code, music ,cruncher , scroll text etc. This is my humble opinion.
2017-07-05 16:18
Trash

Registered: Jan 2002
Posts: 95
Why must everything be so hard all the time?
Graphics - A still picture possibly with some simple animations on it. It doesnt matter how much code that is used in the background, it is still just an picture expressing the artists lust to exhibit his skill.
Demo: Anything with graphics and sound where the sound isnt made in order to enter a music compo.
Tool: Something that may be useful to someone.
Music: Guess what? A SID-file or a d64 or a prg-file containing a music-release...

But I'd like tags like WorldRecord<YEAR>, WorldFirst and such...
2017-07-05 20:33
Jammer

Registered: Nov 2002
Posts: 638
Distinction between graphics and demos on very code basis apparently leads to truly absurd conclusions. I cannot find anything more logical than pic being animated and sounded or not (don't count flicker or scroll in, please :P).
2017-07-05 21:07
soci

Registered: Sep 2003
Posts: 357
If the coder spent more time on the release than the graphician than it's a demo.
2017-07-05 21:18
Groepaz

Registered: Dec 2001
Posts: 8154
does that make all JSL releases demos? =)
2017-07-05 21:25
algorithm

Registered: May 2002
Posts: 682
Just call everything a "c64 production" and be done with it! :-)
2017-07-05 21:30
soci

Registered: Sep 2003
Posts: 357
Most of his latest stuff are demos anyway.

I've almost choose demo for this back then. And this was fun to do as well.
2017-07-06 20:12
Compyx

Registered: Jan 2005
Posts: 268
Quoting soci
If the coder spent more time on the release than the graphician than it's a demo.


How would that work for new formats? I usually code my own native editors for some new/non-standard format.
And actually coding and testing the editor usually takes longer than finally creating an image in it. (Admittedly I'm both the coder and the graphician, so in my case it's a bit of a grey area)

How about this: if there's a publicly available editor for a given format and the release has the image in a file format handled by the editor, then it's graphics. If the editor is not publicly available, or music/scrolls etc. are added, it's a demo.
2017-07-14 01:00
Copyfault

Registered: Dec 2001
Posts: 208
Isn't the chosen category of a release more or less an important part of the release itself? The artist (I choose this phrase on purpose!) wants his product to be seen as a certain thing, so by choosing the category the artist also puts a focus.

As said before nobody seems to discuss if it is necessary to distinguish between a "normal" music release and a music release with coding tricks (would multiple speed tunes be "normal" when thinking this way???).

For me everything that exclusively outputs a static image (be it interlaced or no) is a graphic - just as everything that outputs sound (and nothing more) is a music release.

Defining a gfx with dependence on available editors would outrule any future gfx mode - which I think is a valuable ingredient of the c64's magic.

But then again, I'm looking at this with a coder's eye, and -as with everything connected with art- milleague may vary ;)
2017-07-14 01:17
Groepaz

Registered: Dec 2001
Posts: 8154
Quote:
Isn't the chosen category of a release more or less an important part of the release itself? The artist (I choose this phrase on purpose!) wants his product to be seen as a certain thing, so by choosing the category the artist also puts a focus.

the artist should then explain whatever he thinks needs explaining on his website, in the release, in a readme... or whatever.

however, entries in csdb are not about what some artist thinks or demands it to be.
2017-07-14 23:06
Compyx

Registered: Jan 2005
Posts: 268
Quoting Copyfault

Defining a gfx with dependence on available editors would outrule any future gfx mode - which I think is a valuable ingredient of the c64's magic.


Thought about that too, perhaps the first time a 'new' gfx mode is released, we call it a demo. And future releases, when an editor is available, can be called graphics.
2017-07-15 14:40
Deev

Registered: Feb 2002
Posts: 150
Is the problem here that we’re trying to rigidly fit everything into one category, when sometimes a release could actually fit a number of categories? Databases cataloging music, film, art etc. wouldn’t usually restrict an entry to just one genre/theme, because many releases break those boundaries.

If someone invents a new graphics mode and it’s first released as a standalone picture, that release should be categorised as a demo, but if we would categorise every release that follows as a C64 graphic, then to me it makes sense that the first release should also be a C64 graphic.

If you strip things down purely to the functionality of a database (as always seems to happen when people suggest new features), then you should certainly be able to query graphics in a certain mode and receive all releases in that mode, including the first. Similarly, you should probably be able to query something like "demos which premiere a new graphics mode".
2017-07-15 17:55
Oswald

Registered: Apr 2002
Posts: 4065
yep, pointless to argue, releases will never only fit certain boxes.

maybe tags could help, then a release could be both gfx and demo :)
2017-07-15 23:53
Shine

Registered: Jul 2012
Posts: 196
Quoting Oswald
yep, pointless to argue, releases will never only fit certain boxes.

maybe tags could help, then a release could be both gfx and demo :)

Yep i agree. Tags would be a very fine feature generally!
2017-07-16 14:31
Copyfault

Registered: Dec 2001
Posts: 208
Quoting Groepaz
Quote:
Isn't the chosen category of a release more or less an important part of the release itself? The artist (I choose this phrase on purpose!) wants his product to be seen as a certain thing, so by choosing the category the artist also puts a focus.

the artist should then explain whatever he thinks needs explaining on his website, in the release, in a readme... or whatever.

Yes, that would be fine (though when having "real art" in mind, a f**king lot of artists never shared their thoughts on their productions, leaving the consumer alone).

Quoting Groepaz

however, entries in csdb are not about what some artist thinks or demands it to be.

But the release itself is! And as a db for gathering information on everything C64-scene related the CSDb-entry should just reflects that, no?
2017-07-16 14:42
Groepaz

Registered: Dec 2001
Posts: 8154
the point is that all entries should be categorized using the exact same rules. once it is allowed for everyone to apply their own ideas, chaos is the result. (and thats also why users cant add random tags)
2017-07-16 14:58
hedning

Registered: Mar 2009
Posts: 1288
Quote: the point is that all entries should be categorized using the exact same rules. once it is allowed for everyone to apply their own ideas, chaos is the result. (and thats also why users cant add random tags)

+1
2017-07-16 15:08
Copyfault

Registered: Dec 2001
Posts: 208
Quoting Han
On other systems (i.e. PC) the differentiation is quite simple and could be applied to the C64 as well. At least as a rule for entries at demo parties: Only pure data-files are allowed for the graphics and music-compo. That means the picture or soundfile must be delivered in a well documented format and the organizers define which formats are allowed. On PC that usually means JPG and MP3/MOD.
[...]

I think this won't work as graphics on C64 are not that standardized* like e.g. on PC.

But the idea to look at how it is handled on other platforms got me thinking. Ususally there are certain boundaries given for resolution and the amount of colours (for example, a PC gfx release must be 1920x1080pix max @ 32bit colour depth on most parties). What about carrying this over to C64, so everything that is 404x312pix@16Colours** is a valid gfx entry for a compo. Choosing the C64's colour palette, this would only allow C64 gfx releases**; choosing a different palette would result in what is nowadays called Oldschool GFX iiuc.


*) this ofcourse reveals I'm still a fan of explicitly allowing fancy modes for gfx-releases

**) I know this ignores the different C64-specific restrictions in/outside the main 320x200 screen window but I just wanted to give a first proposal.
2017-07-16 15:19
Groepaz

Registered: Dec 2001
Posts: 8154
somehow i dont get what the problem is with this at all. "prg file that can be run and shows a still picture" is pretty clear to me.
2017-07-16 21:17
Moloch

Registered: Jan 2002
Posts: 1615
I've held off responding to this long meandering thread so that everyone could get their pet ideas about categories out. To me the c64 scene is partially about putting your own little spin on things, trying to be original and creative on a very limiting "toy machine" by today's standards. So it is understandable when a clean cut consensus about release categories can't be made. I knew the thread would be long winded and nobody, outside of a few current and past staffers, would truly agree on what is and isn't a "graphics release" or a "one file demo".

Quoting Groepaz
the point is that all entries should be categorized using the exact same rules. once it is allowed for everyone to apply their own ideas, chaos is the result. (and thats also why users cant add random tags)

and

Quoting Groepaz
somehow i dont get what the problem is with this at all. "prg file that can be run and shows a still picture" is pretty clear to me.


... and these are music entries ->
Flat City
Shapeshifter

Anything more elaborate than those examples aren't music entries and should be filed under "one file demo". If your "music release" would be categorized as a demo in the late 1980s, guess what, it is still a demo in 2017.
2017-07-16 21:31
Shine

Registered: Jul 2012
Posts: 196
Fact is, that there are a couple if missunderstandigs / ambiguities with "release types".
This thread is a proof of this (at least).

Let us try to improve CSDb with features which increase the transparency for example.

Or do you think CSDb is perfect like it is? *sigh*
2017-07-16 22:03
Moloch

Registered: Jan 2002
Posts: 1615
Quoting Shine
Let us try to improve CSDb with features which increase the transparency for example.

Or do you think CSDb is perfect like it is? *sigh*

CSDb is far from perfect, but it also isn't a democracy. Very rarely does anything come out of these threads that is useful for the staff. When something does catch one of the staffers eye we then have to get the rest of the staff to agree (not easy) and then wait for the changes to be implemented. There is already a long list of features and functions that need to be implemented, large portions of which have been on that list since pre-2014.
2017-07-16 22:07
Shine

Registered: Jul 2012
Posts: 196
Quoting Moloch
There is already a long list of features and functions that need to be implemented, large portions of which have been on that list since pre-2014.

Well, then there is hope for all of us! :D
2017-07-17 13:47
Nemezis

Registered: Jan 2002
Posts: 21
What is the difference between "One file demo" and "Dentro" ?
For example - Obornik
Why is it not even ranked in "Top onefile demos" ?
2017-07-17 14:03
Groepaz

Registered: Dec 2001
Posts: 8154
"dentro" is a stupid amiga-scene term that shouldnt even exist in this database.
2017-07-17 14:41
Nemezis

Registered: Jan 2002
Posts: 21
It was a term for multi-part one file demo without blank screen/no sound/decrunching breaks between parts, and as far as I know "Obornik" by Elysium was first. It is still "One file demo" anyway, like Dawnfall.
2017-07-17 14:47
Groepaz

Registered: Dec 2001
Posts: 8154
the original meaning of "dentro" is like "preview for a demo that is yet to come"
2017-07-17 15:00
Nemezis

Registered: Jan 2002
Posts: 21
So this definition is very different from what Brush was thinking about making this "first dentro in C64 history".
2017-07-17 18:23
ChristopherJam

Registered: Aug 2004
Posts: 644
Quoting Groepaz
somehow i dont get what the problem is with this at all. "prg file that can be run and shows a still picture" is pretty clear to me.


^^ yes, this.
2017-07-20 14:47
Joe

Registered: Apr 2002
Posts: 139
Nice read! Who cares what category things is put into; we still miss those hash-tags for easier browsing.
I'm perfectly fine with whatever comes out from this scene, regardless the heavily debated label it gets ;D
2017-07-20 18:09
Jammer

Registered: Nov 2002
Posts: 638
Demoscene - the highest pinnacle of autism ;)
2017-07-20 19:08
Compyx

Registered: Jan 2005
Posts: 268
Quoting Jammer
Demoscene - the highest pinnacle of autism ;)


Fixed, pinnacle already implies highest :)
2017-07-20 19:44
Jammer

Registered: Nov 2002
Posts: 638
Quoting Compyx
Fixed, pinnacle already implies highest :)


HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!

+1000 sir :D
2017-07-23 18:05
FATFrost

Registered: Sep 2003
Posts: 204
@Groepaz, i always thought a Dentro was a mini demo/intro that's wasn't big enough to be classed as a full demo.
2017-07-23 18:21
Groepaz

Registered: Dec 2001
Posts: 8154
does not compute. those "dentros" are typically bigger than regular onefile demos (they typically have more than one part)
2017-07-23 18:57
Compyx

Registered: Jan 2005
Posts: 268
I also thought dentro was what Fatfrost said. Let's keep that weird definition out of this discussion then. It's not like we lack input right now ;)
2017-07-23 19:34
Hein

Registered: Apr 2004
Posts: 800
A bunch of scientists discussing c64 scene db classifications. This discussion will never end, because nobody wants to update those release types manually once the definition is settled. You've created a monster, dr. Perffenstein!

Dentro and trackmo are actually equally cool marketing terms.
2017-07-23 19:34
Adam

Registered: Jul 2009
Posts: 184
Quoting Groepaz
the original meaning of "dentro" is like "preview for a demo that is yet to come"


I have not heard of it used on c64.. not that I can remember. I first recall seeing 'dentro' used on the Amiga.. and even then I couldn't make much sense of the term.
2017-07-23 19:53
Groepaz

Registered: Dec 2001
Posts: 8154
yeah its an amiga term that for some reason some people transferred to the c64 (where it doesnt make a lot of sense at all). the same can be applied to "intro" for "small demo". those are originally little demos that introduce an amiga bbs.

just delete those terms from c64 context, problem solved :)
2017-07-23 20:21
hedning

Registered: Mar 2009
Posts: 1288
The stupid term "dentro" was used in the Atari ST scene as well, and as I remember it it was used on demos that fell in between demo and intro, thus "dentro". *sigh*.
2017-07-23 21:51
Moloch

Registered: Jan 2002
Posts: 1615
Fantastic, something did come from this thread ... delete dentro category and mark all of them one-file demo.
2017-07-23 22:09
Groepaz

Registered: Dec 2001
Posts: 8154
\o/
2017-07-23 23:02
Jammer

Registered: Nov 2002
Posts: 638
What Moloch said.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Claus_2015
The Overkiller/Hokut..
Slaygon/Censor Design
JEZ
Jammer/TooMany
saimo
Guests online: 42
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Quad Core 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Lunatico  (9.6)
7 Comaland 100%  (9.5)
8 Incoherent Nightmare  (9.5)
9 Wonderland XII  (9.5)
10 Comaland  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.6)
2 Field Sort  (9.6)
3 Dawnfall V1.1  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Treu Love [reu]  (9.4)
6 Dawnfall  (9.2)
7 Veterans of Style  (9.2)
8 KAOS 64  (9.2)
9 One-Der  (9.2)
10 Game of Thrones [2sid]  (9.2)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 Oxyron  (9.4)
4 Crest  (9.3)
5 Finnish Gold  (9.3)
Top Fullscreen Graphicians
1 Veto  (9.8)
2 Joe  (9.8)
3 Mirage  (9.7)
4 Jailbird  (9.6)
5 Hein  (9.5)

Home - Disclaimer
Copyright © No Name 2001-2017
Page generated in: 4.375 sec.