Twilighte wrote:
Yes, i understand the space saving idea, especially since we are fast running into memory problems. I suspect you are thinking we should release this Space:1999 without Dbug optimisation and to me that sounds quite a good idea. Not because Dbug would not make improvements but because the first game can potentially be a proof of concept. I also think all the stuff you have achieved over the last year with this project must be paying its price by now in exhaustion?
Exhaustion? Well, nearly
but I have patience... As there is so much to be done yet (we don't have inventories, nor plot, nor sound, nor a game itself) we may have time to include that improvement. On the other hand, indeed its most a proof of concept: really it is a test to see if WHITE+NOISE layers conform a usable engine.
About this, Dbug, I did not remember to tell you that one place where optimization in speed can be important is in the drawing of rooms (check routine _draw_room in iso_funcs.s) which implements the algorithm I posted some weeks ago. It loops through tiles performing the stacked drawing and updating screen coordinates. When in double buffer mode, put_sprite and put_sprite2 check if the graphic intersects with the area to be redrawn, so the only overhead is the loop itself.
I also have an array with bitflags (8 per tile) that indicate if there are blocks or characters to be drawn, so the checks are quicker. In theory, you should check all the tiles, but with the restriction of having graphics of 4 scans maximum, you noly have to check a strip (if we had also a limit for height, more restrictions could be applied, but I think it might be not worth it):
Code: Select all
; We are in double buffer mode, so:
; tile is (iloop2,tiley) for (i,j)
; let's see if we need to draw them
lda tiley
sec
sbc iloop2 ; calculate (j-i) and compare with original
sbc tilex
bpl cc_notneg
sta tmp
lda #0
sec
sbc tmp
cc_notneg
cmp #5 ;; WARNING: WITH 4 THERE ARE SOME CASES IT DOES NOT WORK!
bcs dr_no_paint
Notice that tilex has an old name that does not really represent its content, it keeps the difference (j-i) for the tile we are updating the screen around (normally the character location)... this happens often in these old loops, so be careful (sorry for such nightmarish code
I planned to clean it up before releasing...).
I suppose all this could be changed so it only loops for the tiles we already know that should be drawn, reducing greately loop overhead (which is quite large). But as the loop also updates screen coordinates, a function that translates (i,j) tile coordinates to (x,y) screen coordinates is needed. I have one (ij2xy) but it is not quick enough. Maybe a table can help here? Maybe with some trick to avoid having two 100-byte arrays?
Have any ideas about the inverted walls being in the "wrong" side? Anything that can be done with some kind of graph trick and avoid me a headache?
I'm glad you mention this, because the curved cut-out walls at the front occupy the "right side" so that they will look right when the player moves up to them.
I think this can also be done for some other cut-outs. Infact i may have got the design a bit wrong... i am thinking... Border walls should be possible to place so that it avoids this issue.
However internal walls are more tricky, i shall try to design some that are better placed toward the centre lines of each tile.
Good... That is what I meant. Let's see if that solves some problems. The real matter here is that thick walls that occupy one tile (almost) do not look good for Space 1999... It would do for a dungeon or a castle...
Anyway, i hope it all goes well for you in Boston, is it for Business or Pleasure?
Thanks. Bussines... I will attend a conference (Optics East) with matters related to our work at the university, but I will find some time for sightseeing
as previously discussed.
