Is it a good "trick" for 32x32 sprites?

Página 3/4
1 | 2 | | 4

Por hit9918

Prophet (2867)

imagem de hit9918

26-07-2014, 20:26

well you may smell it, I dislike the idea Wink
the Y regions that nobody can cross = zero gameplay.

to have gameplay, all sprites would need to be magnified.
and then there are very tight borders for the game to not appear as minor.
the whole background world must fit it. there is a "whole picture plot" thing.

like square skyscrapers of defender or something.
on a sidenote I like atari 2600 defender backgrounds more than arcade.
arcade has lines drawn in BASIC, 2600 has skyscraper.
look here:
http://www.youtube.com/watch?v=PrLS2S0Cp8U

On a sidenote, can you see how the video port adds the 24bit shading to the monochrome?
real machine is just less synthetic.

Por MäSäXi

Paragon (1884)

imagem de MäSäXi

27-07-2014, 14:39

Ok, thank you, more than nice to hear it´s Possible! Big smile One more MSX dream just came true! Smile

Yes, with "software sprites in a box" I meant just that, 8 pixel movement. 8 pixel movement, because in my example huge dragon moves through the detailed background. Magnified huge hardware sprites dragon moves smoothly without spoiling background and does not need to live in the box! Wink Tongue

Yes, I noticed player´s mothership in Uridium, it´s surely software sprite. Smile Software sprites are great things to make MSX1 games much more colourful, I have nothing against colourful software sprites and I don´t afraid possible box-like look of certain software sprites,but I was just thinking that magnified hardware sprites allow huge dragon to go through the detailed background, without needing to check where to draw background again and again. And also because I want to see two sprite magnification modes used at the same time. Wink

Por MäSäXi

Paragon (1884)

imagem de MäSäXi

27-07-2014, 15:03

You haven´t yet answered what happens when magnified sprite´s top pixel row moves into same scanline as normal sized sprite´s bottom pixel row?

Will it have effect just in those top/bottom row pixels of other/both sprites? In that case, will there be, in example, magnified sprite, which top row of pixels are in normal size?

Or will other sprite change it´s whole magnification mode, not just few pixels?

Which sprite will change it´s pixels or it´s magnification mode?

Will both sprites change between magnified and normal all the time?

Or will there be some strange sprite garbage on every part of those scanlines where "two magnification modes meet" or will there be sprite garbage anywhere in the screen?

I would be very glad to know. Smile After your answers it´s easier to get ideas to get over "zero gameplay". Smile Like you have read from my examples, not every sprite in the game must be in the same scanline, just like in my example, birds,dragons, planes, helicopters and spaceships can fly in the air, above walking/driving player/car. And in the air, there could be different magnification mode sprites in different heights (in different scanlines).

No problem if you don´t know the answers yet. Smile I did understand this is not your favourite idea how to make great MSX1 games, but I would really really much appreciate if you could do some tests for it. Please! Smile I am not asking this just for MSX, I think it will open a whole new world for any other still living computer and console with Texas Instruments graphics chip inside. Or at least gives a possibility to get fresh new ideas to game design and graphics. I think I am not the only one who likes the idea of mixing normal sized and magnified sprites in computer games. Big smile

Por Grauw

Ascended (8442)

imagem de Grauw

27-07-2014, 15:00

Hey MäSäXi,

I like your ideas Smile.

I suspect that the sprite lines above the screensplit will be magnified, and below will not be, but the best way to know is to try!

Por MäSäXi

Paragon (1884)

imagem de MäSäXi

27-07-2014, 15:22

Thank you Grauw! Please read again the bottom part of my message, I just added there few lines more. Nice to hear I am not the only one. Thank you! Smile

There are lot more ways to get very nice effects to games by mixing sprite magnification modes, like making vertically moving enemies "come closer to the television screen" in certain scanlines, demo makers can get nice effects too, in example for vertically moving scrolltext, sprite alphabet letters and numbers can be "zoomed" in certain places. Smile

Also, it can give a "more lifelike" effect to horizontally scrolling space shooters, as sometimes enemies can fly "nearer". In certain cases in certain games, like some bird´s eye view games, it can allow player or some enemies jump in the air, as they come "closer", it looks like jumping. Smile Sure, this doesn´t work in every situation, but game enemy movement routines are just that anyway, in many cases enemies cannot do what they want anywhere they want, but just in certain places or in certain moments only.

I strongly suggest that people should start get thinking new ideas about this mixing magnification modes. I do understand that it is a new strange thing, as MSX´ers are not used to mix normal sized and magnified sprites as it is/was not possible. Smile But it can give very very nice effects to new MSX games. Smile

Por hit9918

Prophet (2867)

imagem de hit9918

27-07-2014, 17:07

Quote:

You haven´t yet answered what happens when magnified sprite´s top pixel row moves into same scanline as normal sized sprite´s bottom pixel row? "

I already answered before you asked Big smile "sprites cant cross the line", "zero gameplay".
thinking of VDPs Y comparisons, sometimes things disappear, sometimes ghost snippets appear.

let me guess, you got a C64 game in mind and want exactly that look, including the bad things Wink
missing big sprites on MSX is one thing.
missing exactly same pixels as another machine is a completely different thing.
if C64 NES were asked to do screen 2 games, they would fail completely.

Por hit9918

Prophet (2867)

imagem de hit9918

27-07-2014, 19:24

But quite some of those dreams still could be done. It is just coded different, the rest all works, ok? Smile

For example the shooter with the zoom enemy attacking.
Instead of one step turning to blocky sprite, the whole thing is a hires movie of same size Big smile

The tech used:
nemesis uses 2 sprites for the player. using a software sprite instead.
no blocks, 100 milliseconds before you bite the dust, thing turns hardware sprite to not make bleed on the ground Smile

Now the amount of enemies that you can face without flicker is 200%!
That is same as the magnification thing. Except that actualy works and keeps gameplay.
And I thought of a sprite pattern cache. The game can have lots more animation.

Nemesis wastes a second sprite on the player for 3 mildly interesting red pixels of cockpit.
A ship with its lower side in darker color is as nice.
Actualy when you pull up you get a different sprite with the lower side dark, it looks more nice.

Short, a nicer ship, 1 sprite per scanline, without software sprites getting a budget increase to 150%.

The player is a critical thing because he is in unknown location.
Having that unknown load removed is a bit like increase the whole DMA to 150%.
In this case just by player sprite design.

MSX2 9938 screen 5 scroll game:
If you can find time in the blank to make one software sprite for the player,
removing two sprites off the unknown lines, it again is like 150% hardware sprite DMA increase.

Por MäSäXi

Paragon (1884)

imagem de MäSäXi

28-07-2014, 20:58

Quote:

to have gameplay, all sprites would need to be magnified.
and then there are very tight borders for the game to not appear as minor.
the whole background world must fit it. there is a "whole picture plot" thing.

like square skyscrapers of defender or something.

Oh, are you worrying that beautifully designed hi-res background would look out of place with blocky magnified sprites? Please do not worry about that! Smile Yes, I saw those shadings in that video. Smile And I was playing Defender arcade game when it was not very old game yet. Wink I still recall that feeling how those line drawn red mountains felt like! It felt as an unique idea back then! Smile

Quote:

thinking of VDPs Y comparisons, sometimes things disappear, sometimes ghost snippets appear.

I still hope I could try and see some test programs about that, so I could see how bad or acceptable "ghosts" can appear to screen while moving magnified and normal sprites. Smile

Actually, I didn´t have any particular C64 game in my mind when I started to ask about this thing. Things I got in my mind were my ideas, which I mixed from tens of different C64 games. Smile I can want same look of certain C64 game for MSX if I know it IS possible somehow, if I know it´s not possible, I will try to think it different way how it can be done on MSX. In some cases I may miss exactly same pixels from different machine, but I know that in some cases just different screen resolution makes it impossible to want exactly same pixels and Commodore´s and Atari´s sprite stretching abilities also makes it "impossible" to want exactly same pixels. I know that and that´s why I am not wanting everything. Smile

Yes, you are talking wise words about how one could use software sprites. Smile I am just hoping to see some same nice effects what were used in many early C64 games. As I do like simple and sometimes blocky graphics of early games, and as MSX came a bit too "late" to Europe, it didn´t get too many such like games, so I just hope I still could get a more chances to see and play samelike homebrew games with my MSX nowadays so I could kind of relive my childhood dreaming such homebrews were made in early eighties already for MSX. Smile And yes, I would like to see such effects on MSX games also just for it-IS-possible´s sake! Big smile And to enjoy such graphics on MSX! Smile

Por hit9918

Prophet (2867)

imagem de hit9918

29-07-2014, 02:14

Well, you're sooo obsessed with that imagination that it must be done with magnified sprites Wink that it's no more about realistic dreams.

It seems the scroll thing is possible and now the other thing that people always missed is big sprites.
Something different than always that 16x16 pixel sprite thing.
Now the CPC fatpixel gets praised and in even more desperation you would accept crazy ghost fragments popping up Tongue So I guess that with the software sprites I am talking you wouldn't spot bleed but horray fight with big sprites.

A thing with stepping outside the usual genre is that this needs coding new engines and graphics tools.

Por MäSäXi

Paragon (1884)

imagem de MäSäXi

29-07-2014, 18:20

Smile

I think this magnification thing just needs few test demo programs first. Smile I am not going to accept everything, do not worry. Smile I am just thinking, that small "ghosts" which might appear sometimes and only in some situations might be acceptable, but cannot say anything better unless I can see some test demos which show such ghosts and how it really looks like when sprites with different magnification try to enter same scanline.

I am not saying this new magnified sprite thing will remove all problems with software sprites and I am not saying software sprites should be always changed to magnified sprites to get bigger moving characters. No. Smile Like I have tried to say, I would just like to see such big blocky magnified sprites in use with normal sized sprites in some games. And if needed, both in their own scanlines, normal size ones never meeting magnified ones. I guess you have seen at least some games which have hardware sprites travelling left and right only in their own scanlines. Smile (with the exception of bombs and bullets) Yes, I am not saying this magnification thing should be used in all games. I just hope it could be tried in few games at least. Smile

Página 3/4
1 | 2 | | 4