Karoshi MSX Community

(http://img213.imageshack.us/img213/7325/viewpointmsx9jh.png)

i know is extremelly hard to recode this to msx1 (i tried to simulate a picture with msx1 limitations) - but btw would be very interesting a shooter like this on msx (isometric like this for msx1 i only know Zaxxon...)

I also remember Bomber.

Have you used your routines to convert a snapshot from another platform? I still use your routines to convert from PC Paint to MSX.

Anyway, redraw the graphics is not the problem here.

The most difficult problem here is the lack of smooth scroll. Note that a diagonal scroll would be here a problem because could not be made using char scroll 1x1. The perspective used is not 1-1 (45º).

Cool!, it's a very good conversion to SC2!  :)
It's one of the simpler screens of the game, maybe could it be good to try with other screens like the sliding barriers.

Nice screenie, nitro!

Troubles with this one (imo):

- Enemies cannot be done with patterns (due to the detailed background). So ships, shoots, items, etc... should be done using hardware sprites (a lot of flickerin' here!)

- The scroll. If a minimal amount of tiles exist, it can be done using pattern redefinition and name table scrollin each 8 pix. but the scroll must be 2 pix x, 1 pix y (as robys said, it is not a regular angle)... hard, but it can be done.

It could be a nice project... anyone wanting to make a concept proof scroll demo? :wallball:

O_O WOW! Viewpoint!

Great game (I have the Neo Geo CD version somewhere) but the diffuculty is very high if you are not comforable with the control system.

A bit of practice never hurt tho ;)

Maybe the non simmetric scroll could help to place the sprites without too much flickering ...after all it's not a classic horizontal shooter.
I believe that using the 3 sprites per object technique, some good result could be achieved. Anyway I'm only guessing.  ::)


Indeed, some really good pattern magic needed here.  :-\

Very nice game!On MSX we have several examples of similar purposes,like Zaxxon....And my favourite,DEMAND.Simply,smooth,and very addictive  8) 8)

KNM
Prepare to launch!

Dioniso: the picture were done by hand over a screenshot...

JlTurSan: this drawing is simple to take a look how it should look like - i'm curious to see how all these more complex stuff would look like too

Robsy: as said ViejoArchivero, i imagined scroll like 2x 1y like Xevious - a staired scroll would look more weird (like 1x 1y, 1x, 1x 1y, 1x, etc.. ), but maybe more coerent with the natural scroll combined with the ship motion scroll, as it is in the NeoGeo version (...?)

ViejoArchivero: i imagined hardware sprites for the small enemies, and character-based for the larger ones - the blank background for the character-based sprites would be like an average background colour (...?)

I've never managed to pass the first stage... :P. I'm curious too about how it looks (the original!) in greater levels. ???

afaik there are 4 stages, or more?



i need to improve the converters anyway - there are some results i'm not getting exactly what i wanted - btw i started these converters from more than 6 years ago, and some code i forgot what they used to do...


for those small sprites, i think the Knightmare1 technique (3 sprites, using 2 sprites per line as limit) should be fine - for the controlled ship, for example, the bottom as black for the shadow, mid and top were blue and white...



i have it a bit in mind, but for me for now would be hard to do it in assembler... :-(

My idea would be a x-offsetting 32 blocks horizontal (128 characters, 1024 pixels) in a vertical scroll - or a bit like it...

The one I use to convert BMP to SC2 creates some wrong datas, but since I know what the program does, I change the wrong values myself.

I do remember that "Jet Bomber" had smooth scrolly...  and Sega´s other version of "Zaxxon" also had a lot smoother scroll compared what their  "Zaxxon´85"  had... 

suggest a game
viewpoint



I found this old code i think i told about it before - i didn't test it yet (the variable and array names are too long to msxbasic, anyway...) - is a bit like msxbasic, but it were more a kind of algorythm i were planning to recode in assembler (laziness and lack of skills...)

This code were more for topview scrolling-down games, also scrolling horizontally depending of the x-position of the player (from arcade, just like Vulgus (Capcom) , Ufo Robo Dangar (Nichibutsu), Flying Shark (Taito), etc.)

The code for Viewpoint, Zaxxon, and whatever, wouldn't be that different at all - the map strip seems to be vertical, with a continuous horizontal scroll (with the x position of map mod64 or mod128) 2 times faster than the limited vertical scroll - the scrolling logic is the same

The idea of the code is: the display redraw (y=0..23,x=0..32) would get it from the position we are in the map, assuming usually the 4x4 character cells we would almost all the time get them partially (for this i'm using mod4)- x4 and y4 would read the current cell from the map, and xm and ym would read the current drawing character from the cell choosed from the x4 and y4 from the map

This code would work as well on that multidirectional platform games like (from arcade) Toki, Black Tiger, Ghosts'n'Goblins, etc. (even Sonic...), or even like that multidirectional topview shooters like TimePilot84.

viewpoint has indeed 6 stages...

a screenshotted map of screen1 explains a bit my idea about how the game scroll would work (afaik)
http://img510.imageshack.us/img510/9030/viewpointmapstage16fu.png

So, a complete mapped level, how many virtual screens will occupy?

If I'm understanding the schema, every "virtual" screen is build by 16*12 4x4 tiles, isn't it?. And you show only the map window under the player position...
If the scroll is always a character one (8 pixels), how can it be implemented to match the 2:1 ratio(x:y) speeds?

Still thinking... ::)

hmmm... the whole map 32x80 blocks (4x4 characters) displaying around 8x6 blocks

the map motion is continuous (2x1 pixels virtually, (  int(x/8),int(y/8) for the display, in that text 8x8 mode  )  for displaying in text mode) , but  the sprite position is always interfering with the map display  - that's why i'm not thinking about using 2x1 characters (i have not the 'exact' or close algorithm for this yet...)

about the map, the bottom 32x64 blocks are continuous, and the upper 32x16 is looping

here is a sketch i did on sdlBasic - i used the whole map in a picture (which is not clean enough, as well i didn't correct the 8x1 colour cell limit) - the pictures are in bmp format because they compress better on 7zip (bz2 compression)

this sketch explains better the idea i have about it - the original scroll algorithm from Sammy is a bit more complex (on my version, if you move back the ship, the scroll simply freezes, and on original version doesn't - and some other more stuff i really can't understand how to get that else working)

btw, even if the result of this remake would be frustrating, this algorithm can be an idea to do similar games (for example, i think there is a similar game coded to x86 computers at early 90's ( 92 or 93, i think), but i can't recall how is it named... (i think it has stuff like alpha-multilayers (semi-transparent), and more impressive enemies motion cadences ))

for the people didn't see the idea of the prototype working yet:
http://youtube.com/watch?v=v48gEUWUawY

Hey nitro!, nice to read you again! :)
Yep, indeed it looks cool (although youtube blurries a bit the demo). Have you keep trying with Z80 assembler?, I'm not talking about a project like Viewpoint (no easy at all); but some more humble ones just to practice.

hi, jltursan!
I got a small pause in the msx development a bit - maybe seeking for other sinergic references could help to pursue trying to develop up-to-now unique stuff on msx, which i (and we all?) think as very welcome in the msx retrocoding scene...

latelly i were posting some videos at youtube - http://youtube.com/user/nitturo - mostly for promoting the sdlbasic as open-source basic interpreter, since i were somehow involved in the development team - and so, sdlBasic were a kind of interesting way to test some ideas i'd like to see working on msx! :-)

what i really dream on unique stuff for msx were games for 4 simultaneous players on one keyboard, on a msx machine:
http://youtube.com/watch?v=Wqchy7OYUco
http://youtube.com/watch?v=1-07NfNwLHE

and what i think as an interesting game on a msx1 were like this one, using those 3d anagram red/green glasses (please try if you have available, or you can make one with those transparent papers, hard paper, glue,  scissors, etc... :-) - you may find some diy instructions at google if needed... ) :
http://www.youtube.com/watch?v=xv6_50rugcU
perfectly possible to be made on a msx1 (afaik) - since all colour attribute area is predefined before, only working on the bitmap area - the problem is coding this with my humble knowledge about z80/msx asm

about 4 player sprite moving, i think i posted here in the snippets area, but i think it got lost when moving now to msxgamesbox server... - of course i'd love to develop better about z80 coding! :-)

before i forgot: since 1 year ago, i'm only using Linux now (and MacOS-X very rarelly) - do you know good z80/msx compilers for Linux? - good idea is if Robsy port his asmsx compiler to Linux as well (and if he decide to make it gpl, who knows being part of the official debian/ubuntu repositories...)