Как насчёт движка для Dungeon Crawl игр?

[Sandro]

В оригинале Принц персидский работал на 64к машинке.
и не жужжал.

А какая именно машинка имеется в виду? Коммодор, например? Ну да, работал. С постоянными подгрузками. БКшный грузится сразу весь, и больше диск не мучает, как я понимаю.

присмотрись к движку Wolf48
там есть что почерпнуть.

От Alone Coder'а? Да, я в курсе, благо он основные решения разъяснил. Но у нас принципиальная разница в устройстве текстуры: у меня битовая карта, у него -- список столбцов одноцветных пикселей. Но я имею в виду, само собой.

- - - Добавлено - - -

Подумалось: поскольку я вольный копейщик, и свободное время у меня находится -- когда как, то выложу я исходники ключевых мест, чтобы интересующимся не приходилось возиться с дизассемблером, и гадать что зачем:

;
; trampoline for the dummy texture (r0 -- offset)
;
tramp1:	add #dummy0 + 10, r0
	clr -(sp)
	mov -(r0), -(sp)
	mov -(r0), -(sp)
	mov -(r0), -(sp)
	mov -(r0), -(sp)
	br texc1
	
;
; trampoline for the half of dummy texture (r0 -- offset)
;
tramp2:	add #dummy0 + 10, r0
	clr -(sp)
	mov -(r0), -(sp)
	mov -(r0), -(sp)
	br texc1
;
;
; draw the pixel column
; texture is 64 pixels high (8 bytes)
;
; r0 - scratch
; r1 - destination pointer (byte)
; r2 - destination column bit mask
; r3 - colors (low/high byte), pre-masked
; r4 - texture coordinate V delta
; r5 - (texture coordinate V fraction accumulator)
;
; stack -- texture terminated by #0;
; TODO run with aligned stack and terminate by tstb sp/beq exit
;
texc1:	clr r5
10$:	mov (sp)+, r0
	beq 19$ ; exit
	sec
11$:	ror r0
	beq 10$ ; next word
	bcc 12$ ; if bit is 1 -- swap colors (TODO -- paired drawing rountine)
	swab r3
12$:	bicb r2, @r1
	bisb r3, @r1
	add #100, r1
	bmi 18$ ; if reached the bottom of the screen -- exit
	add r4, r5
	bcc 12$
	clc
	br 11$
18$:	tst (sp)+ ; unload stack until end of texture is found
	bne 18$
19$:	ret

Это текстурирование. Текстура кладётся на стек, и завершается нулевым словом. Используются все регистры. Для константы 100 (64.) регистра не хватило, увы. Основной фокус -- отсутствие счётчика битов. Вместо этого в сдвиговый регистр (r0) при первом сдвиге заталкивается единичный бит. И если он ушёл, то всё -- надо читать следующее слово (beq 10$).
Сам алгоритм масштабирований классический -- digital difference, то есть дробные приращения текстурной координаты.

- - - Добавлено - - -

Расчёт масштабирования. Ну тут классический алгоритм деления для младших моделей PDP, ничего такого:

;
; Calculate scale of 64-pixel texture to fit it into given pixel count
;
; r0 - pixel count
;
; returns:
; r0 - delta fraction
;
; TODO: 16-bit precision
calctexscale:
	mov r1, -(sp)
	mov r2, -(sp)
	mov r3, -(sp)
	mov #100000, r1 ; 64. * 256. * 2
	clr r2
	mov #16.,r3
1$:	asl r1
	rol r2
	cmp r0, r2
	bhi 2$
	sub r0, r2
	inc r1
2$:	sob r3, 1$
	mov r1, r0
	asr r0
	rol r3
	swab r0 ; multiply fraction by 256 / 2
	ror r3
	rorb r0
	bis #177, r0
	mov (sp)+, r3
	mov (sp)+, r2
	mov (sp)+, r1
	ret

Вот это нужно положить в r4 для текстурника.

- - - Добавлено - - -

Ах да, чуть не забыл: тут у меня 1 бит в текстуре означает инверсию цвета. Т.е. текстура хранится, как последовательность инверсий. Я планирую переделать в нормальный вид, а то так неудобно.

Извините за спам сообщениями

[jerri]

А какая именно машинка имеется в виду? Коммодор, например? Ну да, работал. С постоянными подгрузками. БКшный грузится сразу весь, и больше диск не мучает, как я понимаю.

Apple II исходники доступны.