| |
Oswald
Registered: Apr 2002
Posts: 5031 |
P1
Project One V0.5
post bugreports, questions, feature requests here, should be a better place than the comment area of the release.
|
|
... 276 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Jack, the first part of your idea would work, the 2nd would have problems.
the problem is that you couldnt add new colors, coz every new color would be converted into one of the 3(+background) existing ones.
This would need a backbuffer of the colors that were really put down, and a visible layer of the resulted conversions. Pretty much like Timanthes. So far P1 works directly into an emulated c64 memory, and the picture is based on that.
edit: jack, Im not sure if completely understand u, if there's a clash, then reconvert the char ? |
| |
Jetboy
Registered: Jul 2006
Posts: 229 |
How about adding sprite layer?
That would probably only work on non-fli modes, but there would be some more posibilities. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
sprites will come for sure. but before that the screen handling needs a major rewrite. (OOP instead of arrays and support for different sizes)
The biggest headache with sprites is that what should be supported and what not.
ATMO I think 2 modes should be done.
- mode1: each sprite works as a sprite column, so the height is unlimited. This would make ufli modes easyer to handle.
- mode2: sprites works exactly as on c64. you can define up to 256 sprites, freely positionable, max 8 on the same rasterline etc.
both modes would support change of all sprite attributes, mode1 would let all (or most) attributes to be set on a rasterline basis.
|
| |
Jetboy
Registered: Jul 2006
Posts: 229 |
That would be awesome!
Both modes would have good use.
The second mode would be especialy nice, but there are a lot of problems to solve.
1. It would require custom display routine to be generated for picture. That brings some complication as in some setup changing neccesary sprite properties wouldnt be possible (change all 8 sprites position, mode, color, multicolors, expansion in one line - which may happen to be bad line). It all can be taken into consideration, but it would be titanic work to force editor not to allow such combinations.
2. Two (or more) modes to paint. One - you treat each sprite as separate layer, and must select any given layer to be able to paint on it. You just paint pixels - hard as some sprites/background would be multicolor/hires.
3. it would benice if you could setup sprites position, and sprite number - so you can have multiple sprite data used in different part of the picture - you paint one - and all change. Somewhat like characters and character generators work.
It's alot to think of, and a lot to code, so maybe it is best to wait with those changes after the rest is done. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
the 2nd mode doesnt implies it has to be saved in a displayable selfcontaining prg. the intention is just to be able to edit any sprite / pic setup, then do ur code on c64.
sprite layer mode should take care of "standard" sprite-gfx mode, including saving a runnable .prg. |
| |
Jetboy
Registered: Jul 2006
Posts: 229 |
Yes and no.
It needs to export sprite data somehow - not only sprite definitions, but also colors, modes, positions, etc.
Easiest way would be to do it via self contained prg. That way graphicians wouldnt have to bother coders to implement their ideas which may be impossible.
One idea for restriction is that no 2 sprites can start on the same line. That way there should be enough time to change sprite properties.
edit: Hey Oswald! Those are just ideas im throwing away in hope you catch them. There are no obligations whatsoever, i dont demand anything. If you would use my ideas that would be awesome, if no - that would be excelent too :) Just said that so there is no doubt.
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
:) I know.
'sprite mode1' is to support any weird setup one might need for a demopart. for example to make it possible to edit pictures like the startup pic of deus ex machine. But as a gfx editor I dont think it has to be able to even generate the code necessary to display the picture. It has just to export all the information. |
| |
Jetboy
Registered: Jul 2006
Posts: 229 |
Would that mean you will be able to place sprites all over borders? Neat! |
| |
jailbird
Registered: Dec 2001
Posts: 1576 |
Oswald, IIRC, you have mentioned implementing screen resolutions over 320x200 - that would be quite useful for scrolling pictures and stuff. Just to keep you reminded :) |
| |
Tch
Account closed
Registered: Sep 2004
Posts: 512 |
Totaly off topic,but it sure is good to see Valsary in this thread. 8D
Sorry Oswald,haven´t tried it yet.. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 29 - Next |
