| Posted By
bszggg
on 2024-04-03
10:47:06
|  Standardization questions
Hi!
I have some thinking about file formats in plus4.
Witch file formats and standards available?
I'm thinking on icon. What would be a good choose to it? I found some sprite editor.. that I can use for it to some base app for icon editor.
Sprite_Editor_V1_3
Is that a good format? (I move to $2000 the display to see what is in the memory)
And What is the BIG picture in this situation with graphical standards?
Is there a multicolor sprite standard?
|
|
Posted By
Csabo
on 2024-04-04
10:50:41
| Re: Standardization questions
As far as I know, no such standards exists.
The closest thing to this might be the Multi Botticelli image standard (described on the page). There might be an icon format/standard for GEOS programs.
|
|
Posted By
bszggg
on 2024-04-05
19:55:03
| Re: Standardization questions
Thanks the answer..
Bottichelli is a fullscreen image..
I have found some ideas:
https://c64os.com/c64os/programmersguide/writingapp_tutorial1
https://c64os.com/post/imageformats
So the 3icon it possible okay, (a 3x3 char 2 color icon.)
But I think it needs to make a bigger image structure too, with multicolor and hires, with custom size and palette.. that is possible to use in any application..
And saved as a SEQ file.
Something like This:
filetype : "p4gimg" (plus4 graphical image)
ver :1 ($00 padded and terminated)
type :1 (1 hires 3 multi)
xsizchar :2
ysizchar :2
color :125 max ($00 padded and terminated)
luma :125 max ($00 padded and terminated)
bitmap :1000 max ($00 padded and terminated)
color03 : 2 (ted extra color)
SOURCE :17 (Title, String in PETSCII, $00 padded and terminated)
AUTHOR :17 (Artist, String in PETSCII, $00 padded and terminated)
RELEASE :17 (Copyright, String in PETSCII, $00 padded and terminated)
META :?
And it is easy to use the data that the DFLICONV2GUI present from other images, so we can convert easily. (When use the separate bin file saves, not the PRG one)
Opinion?
|
|
Posted By
MMS
on 2024-04-05
21:40:53
 | Re: Standardization questions
Well, with George we had a different approach.
We had a common project, but dropped to to possible copyright issues (not an issue here in Hungary, but in Germany)
We wanted to load and show small pictures, but finally our idea was to create and load a full (multicolor) picture to somewhere in the memory, then when you need a part of it, just copy it to the screen.
As per our view, it could greatly reduces the disc access, so the loading times.
(eg. in my adventure game I also try to use the same method, all the swords, axes, shields, etc are in one multicolor file (an memory area kep for name, attributes, description), and if you select a new weapon, i just take the necessary area. Sure, it is not complete yet....
The loading and picture copy routine done together with George and gerliczer, and uploaded to the BASIC section related to "loading hires screen", and we use Kernal routines to have some speed.
|
|
Posted By
gerliczer
on 2024-04-06
06:49:49
| Re: Standardization questions
I never heard of any real standards for the 264 series. But what do you expect such standards would achieve? What goals cannot be reached without them? What overwhelming benefits would they provide?
|
|
Posted By
bszggg
on 2024-04-06
14:44:30
| Re: Standardization questions
@MMS
Yeah.. The loading time is on the other side
@gerliczer
How can we make tools for it..
Things that have been made once can easily be incorporated elsewhere.
different software can use each other's stuff.
the meaning of the word "compatibility" would include the benefits.
|
|
Posted By
Csabo
on 2024-04-06
15:02:16
| Re: Standardization questions
Now that you explained a bit more about what you're thinking, I'll add my two cents: there's no real need for something like this. That's also the reason why such a standard never emerged organically, despite the several decades of homebrew projects.
Typically, games will have similarly sized elements. There are lots of examples for this: Adventure Park (which I thought of randomly) has 2x2 character tiles and same-sized enemies. Therefore the code is usually written to handle those sizes explicitly.
Some such "standards" kind of exist though, for example, the Adventure Soft UK games (Rebel Planet, Temple of Terror, and tons of others) have 256*96 size hires bitmaps. These are stored in a very complex, compressed format. The engine that displays them is the same between games, and it's even cross-platform (same gfx on C64, ZX Spectrum). The Bard's Tale animated portraits also have their own format (still fixed size though). Again, these are very game specific.
I honestly can't think of any game that loads and displays variable-sized bitmaps.
Despite all of that, that shouldn't stop you from proposing such a format, but I would not expect widespread use of it.
|
|
Posted By
MMS
on 2024-04-07
04:45:50
| Re: Standardization questions
@bszggg ezért kellene a JIFFY bekapcsolt képernyővel  Tényleg, létezik olyan 1541 gyorstöltő, ami nem kapcsolja le képernyőt? szerintem én még nem találkoztam vele. Ez mondjuk teljesen logikus is, hiszen így az összes raszter pozícióban teljes sebességgel lehet töltetni.
ENG: That's why the JIFFYDOS would be great with switched on screen. But it would cause major speed decrease, maybe 30%.
I know that speed is a key for a fastloaded, but have anyone seen a fastloader on Plus/4 with a scwitched on screen?
(switching off the screen is a 100% logical step, as you can used fastload protocol in each raster position)
|
|
Posted By
gerliczer
on 2024-04-07
06:01:37
| Re: Standardization questions
Each and every trackmo running on our machines has fastloader that has the screen turned on.
|
|
|
|
Posted By
gerliczer
on 2024-04-07
09:35:51
| Re: Standardization questions
And I second Csabo. To achieve best performance in underpowered systems without hardware acceleration you have to optimize evert aspect of the software and tailor it to the needs of the mechanics of the programme. These vary case to case, therefore, there is no one size fits all solution. Standardizing may lower the barrier to entry but, usually, does not help when you aim for the highest achievable quality; and in worst case may lead to a flood of "exactly" the same programmes based on the limitations of the standard, like back in the days when almost every demopart looked like one logo, one scroll and a tune played through a wave-converter, or in one word: mediocrity.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
