Quote:

Everyone agrees that the MSX1 scene is almost dead. There is little activity, despite all my efforts.

Hmm, I tend to disagree. I don't hear many people talk about MSX1 over here, that's true. But no one says 'MSX1 is dead!' (ah well, people say MSX is dead all the time, don't they). Second.. the most downloaded file in our downloads database so far is an MSX1 game, 666 haunted house. People are still interested in MSX1 games, as most visitors of the MRC care more about gameplay or nice ideas than 'superbly rendered cool 3D graphics.. and oh yeah, you can control a few things too!'

Quote:

And the difference is not RAM, as you all know: VDPs. The MSX1 system cannot be compared graphically to MSX2 and higher systems.

I consider both MSX1 and MSX2 to be graphically limited machines, certainly not high-end. That doesn't mean you can't create cool things that look cool on it. Konami has proven the power of MSX1 many, many times and so have all other MSX developers. Same goes for MSX2.

i think the succesfull of msx2 pushing out msx1, is not the graphics in all, are the memory mapper, because in msx1 is hardly program the upper 16kb, then on msx1 the lot of soft only are able to use the middle 32kb as much for code, and a part of last 16kb for variables. In msx1 for use the uppper 16kb the programmer need programming a library set and an interrupt management, or special faster rutine for use that space as data only. With the mapper is very easy because you can select the 3# page at 8000-bfff include from basic if you know how install basic program to &hc000 with 3 poke's writes.

POKE &HC000,0
POKE &HF676,1
POKE &HF677,&HC0
NEW

That moves the Basic bottom to the beginning of page 3.

Quote:

POKE &HC000,0 POKE &HF676,1 POKE &HF677,&HC0 NEW That moves the Basic bottom to the beginning of page 3.

better a " RUN"FILENAME" " instead NEW.

Well... it has been a while, I lost my path to this thread ^^;... j/k, I was a bit busy with the finals and I study in another city so I dont have a pc there.

Well just to talk about some of the subjects I missed in that month...

Ed Robsy, thanx for your idea certainly its prolly the best way to store the maze without any compression, I tried something before reading your idea, I am actually storing the maze with a binary matrix so I just need to know where is a wall (1) or where is a path (0) I know the maze will be different since I wont have thin walls and your game does have them well... maybe I should rewrote some things, anyway I managed to write an recursive algorythm that creates random mazes so maybe I wont be storing mazes in the final game just generating them in different sizes... still dunno at the moment I just can walk through a randomly generated maze and reach an exit not much i know. Btw are you spanish?

About the fact MSX is or isnt dead well, I must say good machines will never die, so while there is someone who still appreciates that machine and maybe someone who can develop things it wont be dead. The same goes to all the machine which arent really hi end one like MSX-2 and such so as I saw so much activity in this forum I can say MSX will last forever .

And about all the latest technical posts I cant say a thing I just did very little in asm so I kinda got lost reading all that stuff, I know the whole freedom is in asm but despite I enjoy having a lot of freedom when coding, I must admit I still need to have some stuff already done by the language, thats why I like c (despite im not very good yet)


Regards,
ronin

Quote:

>>POKE &HC000,0 POKE &HF676,1 POKE &HF677,&HC0 NEW That moves the Basic bottom to the beginning of page 3. << better a " RUN"FILENAME" " instead NEW.

That does the trick too. That NEW was just to adjust the system to its new Basic bottom, and since loading a Basic program in a way does a NEW before it actually loads the program, the result is the same.

Welcome back!

Yes, despite the english surname I am spanish. About randomly generated mazes there are a lot of algorythms out there and most of them check if the labirynth can be finished or not. There are also some algorythms that solve the mazes and they work great. And, lucky you, most of them are in C/C++, so they should be easily ported to MSX.

Kind regards,

Ed Robsy

Good luck porting C++ to MSX!

there are also maze generation algorhythms that always produce solvable mazes

There was a Dutch MSX/SVI magazine in the 1980's that published a Basic listing of such a maze generator.

Thanx Ed Robsy . Well about the randomly generated mazes I found some algorythms that checked if the maze has an exit and other facts such as if it doesnt have infinite loops or inaccesible areas... but the one I liked the most is one where you generate it moving from the exit and following some rules to avoid all the not desired effects (like loops) until you fill the whole thing, its 100% effective since you keep moving through the maze until all the spaces are filled so it is always solvable, and more difficult to solve since you keep movin from exit point not from the starting one, and I tested it doing a prog in a basic language and works great , now I "only" have to find my way to port this to msx ^^;. Btw im also spanish , wasnt there a spanish version of the msx.org?


Edit: I forgot to say that the maze code can be done in plain C so there is no need to use C++... dunno how difficult could it be to port from pure ansi C tho

AFAIK Hitech C is ANSI compatible.
It still might be difficult, depending on the source code, because a lot of programmers wrongly assume an 'int' to be 32 bit, or large enough to store a pointer. In Hitech C case, the int is 16 bit, as is the pointer (but theoretically it could be different ).
One of the things you can do is test on a PC first by changing all the int's to short's. If it still works, the original (not the modified) code has a large chance of compiling as-is on Hitech C.

Quote:

AFAIK Hitech C is ANSI compatible. It still might be difficult, depending on the source code, because a lot of programmers wrongly assume an 'int' to be 32 bit, or large enough to store a pointer. In Hitech C case, the int is 16 bit, as is the pointer (but theoretically it could be different ). One of the things you can do is test on a PC first by changing all the int's to short's. If it still works, the original (not the modified) code has a large chance of compiling as-is on Hitech C.

all good C programmer knows int type must not be used in data structures. char, short or long must be used, instead

int is a word and must be used in loop or temp vars because the optimizer likes to map it on a register

b*llsh*t

Quote:

b*llsh*t

why?