mlynn1974 wrote:Very nice! Definitely looks good.
Points to note:
1. The STOS compiler has a problem at line 820 with undeclared variables:
The code works in the interpreter because they are initialised by goto\gosub the compiler doesn't detect that.
Question for anyone (Charles?): Does the STOS Compiler support forward declaration in other circumstances?
I initialised them by declaring them at line 105\106 and commenting out the declarations at 2040.
2. There is a comment in the code that says don't dim here or something. Why is that?
3. The compiled version loads faster but the mouse pointer is hidden due to repeated switching on and off of the mouse.
I can't remember how to get round that. Possibly carefully use mouseon\mouseoff instead.
4. When starting a game there is debug mouse position info. I thought the code was loading data or something the first time I saw it!
You could switch that off or only show it in debug mode or something.
I look forward to seeing more of this game.
A question that does arise, though, is this - how can I shrink a sprite for when it's drawn in the distance? Or am I reduced to having a "normal" object sprite entry and a "small" sprite entry for when it's in the distance, using up more memory space in so doing?
MM41 wrote:The new configurable keyboard is perfect
I have played all the first floor and i have refinded my 15 years old when i drawing the card
I seen some little bugs: wall not closed according to the angle of view (room of the scroll), sword in the wall,
item changing when approaching (falchion or sword ?).
Some items are difficult to pick up (flickering) and changed when placed on the inventory but normal then cased.
Those bugs must be confirmed by another person (may be SD card fault or hard drive)
It is possible to draw the rail of the grid (when we are on the square grid, we see a normal wall when doing a 360°)
Encolpius i can't wait to see the next evolution of Warriors of light
swapd0 wrote:I can't make it work, also the last two disk images (I haven't tried others) seems corrupted because it has 13.872.738 bytes used, who needs a hard disk? XD
Encolpius wrote:Thanks. I'm glad you like it.
It will be intended to be in real time. The plan I have is that 50 vbls (i.e. 1 second) equals one "tick" and on every tick the game runs routines to decide the movement of each monster, any temporary effects or status effects, etc. It also will check the monster grid to see if a creature has hoved into view and if it has, draws it accordingly. I'm probably going to have to create a routine to do a "limited redraw" if there's monsters round a corner or similar. Otherwise I'm just redrawing everything to no effect. Ten ticks makes a "tock." This would enable me to make attack patterns for monsters or timing-based puzzles - i.e. something like "ON TICK GOSUB Attack(), Spell(), Attack(), Attack(), TryToFlank()," etc.
How I calculate the view? With lots of IF statements. It's not exactly elegant. I have a routine that checks what direction the player is facing and then decides which dungeon squares to interrogate for what should be drawn, then uses a whole load of SCREEN$ calls to composite them on screen 8, then blits the whole of SCREEN 8 to back and physic.
I'm really hoping, in terms of graphical assets, to get nice versions of the walls soon enough. Once that's done I plan to do the same with wall sets, compress them into a single file. While on that subject, I'm all open for volunteers to draw nice walls because I suck calamitously at all things art...
Users browsing this forum: No registered users and 1 guest