Игры аля Doom и Wolf3D для Спектрума...

[Sayman]

Alex Rider, выйди в аську...

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

ну и что, народ теперь кинеца кодить вольфы на zx?))

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

ещё вот исходник рейкаста для z80
http://www.ticalc.org/pub/86/asm/games/maze3d.zip

[Advertiser]

[jerri]

ну и что, народ теперь кинеца кодить вольфы на zx?))

а зачем вольфы? если вольф только один был есть и будет.
смысла в других просто нет

а вот использовать движок для
чего то более другого можно и нужно.

ещё вот исходник рейкаста для z80
http://www.ticalc.org/pub/86/asm/games/maze3d.zip

он не для спека же
и разрешение экрана мелкое

[Sayman]

jerri, говоря про кинеца кодить вольфы, я имел ввиду то, что кодить игры от первого лица, будто шутеры или рпг или ещё что.

он не для спека же
и разрешение экрана мелкое

я пересмотрел парочку движков от калькуляторов. разрешение тут не причём. в одном движке используются вызовы системы (синусы, тангенсы, рисовалки на экран) которые, если я верно понял, на бейсике (подобие наших бейсиков 48 и 128). преимуществ по скорости там нет совсем. Мелкое разрешение нивелируется медленными вызовами, расчётами и выводом на этот мелкий экран. Во втором, что по ссылке выше, там чуть более оптимально. Однако, я заколебался реально приводить в пример все прошлые рейкастинг подобные решения для Спектрума - демка дума, демка цитадели, воль2004, вольф48к и все они куда навороченнее, чем решения (движки) под калькуляторы.
Особенно они выглядят интересными и вкусными, если отойти от темы 3.5мгц, а использовать различные доступные на разных клонах турбо режимы. У меня на моём реале (спринтер) проблем с тормозами нет ни в одном из движков!

Кроме того, чтобы использовать движок вольфа48к надо бы знать его начинку. Я так понимаю, кроме автора про его начинку никто ничего не знает. Допиливать его тут вряд ли кто станет (двери, спрайты, боты, потолок, пол и т.д.).
Я вот в нём не смогу разораться. Мне будет проще (и лучше) разобраться в самой теме рейкастинга и накидать что-то своё. Да, буду это делать долго, что поделать...

[LW]

Кроме того, чтобы использовать движок вольфа48к надо бы знать его начинку. Я так понимаю, кроме автора про его начинку никто ничего не знает.

Там исходников 50кб всего, было бы желание.
Писать с нуля сильно сомневаюсь что будет проще.

[Sayman]

все чего-то молчат по сабжу - или всем пофиг или все активно кодят свои движки?))))
ладно. вопрос на засыпку: в мануале от Ширу есть такой пунктик:

После двух трассировок выбираем ту точку, которая ближе (сравнив найденные расстояния), для неё и будем рисовать столбец.
В приведённом на картинках примере это будет точка E. Нужно бы подробнее рассказать о том, как найти расстояние от игрока до стенки. Есть несколько способов. Расскажу о двух. Недостаток их в том, что в одном нужно считать квадратный корень, а в другом - синус и косинус. Можно и просто посчитать расстояние (X=X2-X1, Y=Y2-Y1), но будет сложнее бороться с искажениями (о них - в следующем разделе).
Первый способ - расстояние от Px, Py до конечной точки Ex, Ey =
sqrt ( (Px-Ex)^2 + (Py-Ey)^2 ). Этот способ неудобен тем, что много медленных операций - два умножения и взятие квадратного корня.
Второй способ - расстояние = abs(Px - Ex)/cos(a) = abs(Py - Ey)/sin(a),
где a = угол луча. Этот способ удобнее тем, что табличку косинуса и синуса можно посчитать заранее, а из медленных операций - одно деление.

так вот. изначально я попёрся по второму варианту. Синус и косинус в табличках. Соответсвтенно dst.dv = ((ax-px)*256)/cosTable[pa] (pa это текущий угол трассера). Но тут есть косяк, т.к. при (ax-px)*256 можно легко словить переполнение "регистра". Т.е. результат выходит за пределы 16бит. Если делать чуть иначе: (((ax-px)*128)/cosTable[pa])*2, тогда падает точность, в среднем на +-1. при этом метод работает на карте примерно до 12на12. Если карта будет больше, 16на16 и более, то снова лезут те же косяки с переполнением.
Получается, что нужно засовывать или первый или второй метод в табличку. От сюда у меня вопрос: как можно завернуть или то или другое в эту саму табличку? пока прихожу к выводу, что это нужно всю карту завернуть туда и табличка может раздуться до х мегабайт, что не желательно. Алоне Кодер как-то через логарифмы завернул это всё по таблицам. Вижу, там 3 или 4 штуки по этой теме. но не могу свести их вместе. Его мозгодробильный код на асме даже не смотрю - есть страх потерять остатки разума совсем))).
Сейчас есть мелкая "рыба" на сях, с честными синусами, косинусами, тангенсами. рисуется в 64на48 с 0.4 кадра в секунду))))

[jerri]

Sayman, а на сях можно быстрее?

не такой уже кстати у него мозгодробительный код

[Sayman]

jerri, на сях можно быстрее, но если делать табличками и с оптимизацией ручной на асме. а у меня почти 100% си (кроме вывода на экран) и нет табличек, пока. все синусы и т.п. в реалтайме, 32бит арифметика, а то и 48 (не помню я сколько там у хайтеха бит для float и double)...
про код алона - ну, ты сам то его смотрел? много там чего понял? формулу/метод его раскусил? а метод у него не документированный, не по permadi/Ширу и даже не по Lodev`у. Что-то своё там...

[jerri]

Sayman, список стен вполне себе по Ширу
горизонтальные/вертикальные.
то как он луч пускает тоже вполне себе понятно.
в край можно просто забрать метод запуска лучей

[LW]

ну и что, народ теперь кинеца кодить вольфы на zx?))

интересно, хоть кто-то занялся данной темой?

[Sayman]

интересно, хоть кто-то занялся данной темой?

ну, Jerri кажется что-то делал, кайдзю, если не ошибаюсь. И с движком Алоновским, он кажется разобрался...