If I had the choice between any fast PC editor (notepad, ultraedit, context etc.) on my adorable TFT, or the best txt editor on my stinky old msx (with an even more stinky monitor).. well.. the choice is easy.

Developing FOR the msx on another system.., nothing wrong with it. Technically it's an improvement to die for..
- fast assembling on a pc assembler
- easy gfx converting/designing, and easy management
- easy soundediting/management
- extremely easy devtools (level editors etc.)

So, what do you have against cross-development ??

l8r.

Wolf, I do not have anything against cross-development. But there's a difference between developing and a drag&drop my-first-demo-generator. Why? Because you don't learn a thing from the latter. Zilch. Nada. Zippo. You only give people the idea they can actually create things. People that use such a generator will not be able to create better things later, they will even be demotivated when they try to make new effects they've seen in other MSX demo's, yet the demo-generator is not capable of producing.

Making the very first step to creating assembly-based demo's this easy makes taking the next step in assembly-coding nearly impossible.

Cross development has nothing to do with a drag&drop my-first-demo generator. Cross development is coding something using a different processor with an executable for another processor. Like Chaos Assembler and tniASM. These are MSX development tools running on a different platform (in this case Win32 based).

Nothing wrong with cross-platform development (actually, a lot of Bombaman is developed on PC too), but a demo maker that will generate 13-in-a-dozen demo's doesn't sound that interesting to me. Compare it with these standard game builders for PC if you will... it's nice, but in the end, there probably won't be a lot of people using it I think...

Or Game Builder that was released by MSX Club Magazine. It too is a generator which hasn't that many game styles to create with.

Quote:

If I understand correctly each sprite pixel will actually be 2 pixels on screen horizontally, but Y resolution will be normal. Correct?

Yes, that's the idea.

Quote:

The timing must be dead-accurate, so I think it's not something to try for beginners

No, timing is very easy as the line that VDP is drawing and the next line, where we are going to scroll the picture are same. Also sprites are same on both lines, so you can't see any visible change before 3rd line draw starts. In other words you have whole line time to change the VDP #23.

I think this is quite a nice effect to start for beginner ASM demo writer. You just need to poll next line, increment VDP #23 by one and repeat this 16 times.

~NYYRIKKI

Uhhh.....Thanks.....I guess .......I have collected as much VDP documentation as possible, at the moment. Going into it this weekend. Will start another thread for this demo and post there my asm listings and questions, ideas etc. So you can still have a laugh or two

oke oke when it is so easy why are so less people making thing like that than????

Idea:

idea-->demo--->game--->more msx fun

you see?

when people are getting the hang of it the will try to create a game and that is the Idea !

Yeah thats the sprite yeah

You assembler gurus could release some of your sources for us less talented people. It would be very helpful for studying assembly coding. I'm currently studying it myself, and searching some simple sources, like "how to display logo on your screen" or "how to scroll text on your screen". Please help, ease our studying...

Quote:

No, timing is very easy as the line that VDP is drawing and the next line, where we are going to scroll the picture are same. Also sprites are same on both lines, so you can't see any visible change before 3rd line draw starts. In other words you have whole line time to change the VDP #23.

Ah OFCOURSE, why didn't I see that ^^;

Quote:

I think this is quite a nice effect to start for beginner ASM demo writer. You just need to poll next line, increment VDP #23 by one and repeat this 16 times.

True, but maybe polling lines (in other words, checking for the HR bit in status register #2) isn't beginners-material, it definitely is a good thing to try for the intermediate programmer. And should look really good too!
You could use more colors on the scroll by setting MSX2 sprite mode colors.. A nice rainbow gradient or something

There's all kinds of ways you could extend this... Wow, what a great idea!!

Quote:

You assembler gurus could release some of your sources for us less talented people. It would be very helpful for studying assembly coding. I'm currently studying it myself, and searching some simple sources, like "how to display logo on your screen" or "how to scroll text on your screen". Please help, ease our studying...

If I'm not mistaken, FuNET is full with assembly files (some in WBASS2 format). You might want to take a look there

Quote:

You could use more colors on the scroll by setting MSX2 sprite mode colors.. A nice rainbow gradient or something

Hmm... If you want good looking rainbow effect, I recommend changeing pallette color in each line. Anyway you may find some nasty usage for offset bit... (This idea is not ready yet...)

Quote:

There's all kinds of ways you could extend this... Wow, what a great idea!!

How about this: Stretch the picture by using SIN wave and make a routine to push it back to original look. Now make a classical sinus scroller on top of the picture with sprites. This should make the sprites alive. If this does not look good enough, you can make the background picture to jump. That will make also the sprites more jumpy.


~NYYRIKKI

Quote:

No, timing is very easy as the line that VDP is drawing and the next line, where we are going to scroll the picture are same. Also sprites are same on both lines, so you can't see any visible change before 3rd line draw starts. In other words you have whole line time to change the VDP #23.

But since VRAM bandwidth is very limited, the VDP fetches the sprite data in advance, on the previous line. This is also the reason sprites always appear 1 line lower than you set them. I think the trick you describe is possible, but it is not as easy as it may seem on a first glance.

Please try to implement it; it would make a wonderful testcase for emulators

But the gfx are eportant as the software himself(sorry for bad english)

Some demo development tips:

Make sure you read the V9938 manual. Again. And again. Knowing the screen modes, the registers etc will give you a feeling for the abilities and limits of the VDP.

Make some small programs to test techniques you'll be using in your demo. Play with them: try if you can do it in less instructions, using different registers, in different screen modes etc. Later you can copy-paste this code in your demo. But because you have tinkered with it, you know what each statement does, unlike when you download some ready-made routine off the net.

When designing a part, think of the effect you would like to see. Start simple, once it works you can add too it. Make some sketches on paper. Then implement it in a high level language, either on MSX or on PC. When you have the algorithm correct, re-implement it in assembly. This way you can get the errors out of the algorithm quickly (not having to rewrite lots of assembly each time you discover a flaw). And later when your assembly code doesn't work, you know it's an implementation error, rather than a wrong algorithm (fixing a bug is easy, finding a bug is hard, so it really helps if you know where to look). I made the copper cube in Almost Real in QuickBasic first, played with the parameters until it looked right and then generated the tables which are used by the Z80 assembly code.

You don't have to do everything in assembly either. You could do all initialisation in MSX-BASIC and then switch to assembly for the actual effect. Then you don't have to learn about BDOS calls, just use BLOAD ,S instead. Even if you want to go all-assembly in the end, start with as much BASIC as you can affort and then replace one piece at a time by assembly.

By the way, there are Pascal and C compilers that (cross)compile for MSX. I never tried them, but others have created interesting stuff with it. It's not as fast as assembly, but a lot faster than BASIC, making it suitable for most effects except for the highly timing critical ones that beginners shouldn't attempt anyway.