Alex Rider, выйди в аську...
- - - Добавлено - - -
ну и что, народ теперь кинеца кодить вольфы на zx?))
- - - Добавлено - - -
ещё вот исходник рейкаста для z80
http://www.ticalc.org/pub/86/asm/games/maze3d.zip
Вид для печати
Alex Rider, выйди в аську...
- - - Добавлено - - -
ну и что, народ теперь кинеца кодить вольфы на zx?))
- - - Добавлено - - -
ещё вот исходник рейкаста для z80
http://www.ticalc.org/pub/86/asm/games/maze3d.zip
а зачем вольфы? если вольф только один был есть и будет.
смысла в других просто нет
а вот использовать движок для
чего то более другого можно и нужно.
он не для спека жеЦитата:
и разрешение экрана мелкое
jerri, говоря про кинеца кодить вольфы, я имел ввиду то, что кодить игры от первого лица, будто шутеры или рпг или ещё что.
я пересмотрел парочку движков от калькуляторов. разрешение тут не причём. в одном движке используются вызовы системы (синусы, тангенсы, рисовалки на экран) которые, если я верно понял, на бейсике (подобие наших бейсиков 48 и 128). преимуществ по скорости там нет совсем. Мелкое разрешение нивелируется медленными вызовами, расчётами и выводом на этот мелкий экран. Во втором, что по ссылке выше, там чуть более оптимально. Однако, я заколебался реально приводить в пример все прошлые рейкастинг подобные решения для Спектрума - демка дума, демка цитадели, воль2004, вольф48к и все они куда навороченнее, чем решения (движки) под калькуляторы.Цитата:
он не для спека же
и разрешение экрана мелкое
Особенно они выглядят интересными и вкусными, если отойти от темы 3.5мгц, а использовать различные доступные на разных клонах турбо режимы. У меня на моём реале (спринтер) проблем с тормозами нет ни в одном из движков!
Кроме того, чтобы использовать движок вольфа48к надо бы знать его начинку. Я так понимаю, кроме автора про его начинку никто ничего не знает. Допиливать его тут вряд ли кто станет (двери, спрайты, боты, потолок, пол и т.д.).
Я вот в нём не смогу разораться. Мне будет проще (и лучше) разобраться в самой теме рейкастинга и накидать что-то своё. Да, буду это делать долго, что поделать...
все чего-то молчат по сабжу - или всем пофиг или все активно кодят свои движки?))))
ладно. вопрос на засыпку: в мануале от Ширу есть такой пунктик:
так вот. изначально я попёрся по второму варианту. Синус и косинус в табличках. Соответсвтенно dst.dv = ((ax-px)*256)/cosTable[pa] (pa это текущий угол трассера). Но тут есть косяк, т.к. при (ax-px)*256 можно легко словить переполнение "регистра". Т.е. результат выходит за пределы 16бит. Если делать чуть иначе: (((ax-px)*128)/cosTable[pa])*2, тогда падает точность, в среднем на +-1. при этом метод работает на карте примерно до 12на12. Если карта будет больше, 16на16 и более, то снова лезут те же косяки с переполнением.Цитата:
После двух трассировок выбираем ту точку, которая ближе (сравнив найденные расстояния), для неё и будем рисовать столбец.
В приведённом на картинках примере это будет точка 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 = угол луча. Этот способ удобнее тем, что табличку косинуса и синуса можно посчитать заранее, а из медленных операций - одно деление.
Получается, что нужно засовывать или первый или второй метод в табличку. От сюда у меня вопрос: как можно завернуть или то или другое в эту саму табличку? пока прихожу к выводу, что это нужно всю карту завернуть туда и табличка может раздуться до х мегабайт, что не желательно. Алоне Кодер как-то через логарифмы завернул это всё по таблицам. Вижу, там 3 или 4 штуки по этой теме. но не могу свести их вместе. Его мозгодробильный код на асме даже не смотрю - есть страх потерять остатки разума совсем))).
Сейчас есть мелкая "рыба" на сях, с честными синусами, косинусами, тангенсами. рисуется в 64на48 с 0.4 кадра в секунду))))
Sayman, а на сях можно быстрее?
не такой уже кстати у него мозгодробительный код
jerri, на сях можно быстрее, но если делать табличками и с оптимизацией ручной на асме. а у меня почти 100% си (кроме вывода на экран) и нет табличек, пока. все синусы и т.п. в реалтайме, 32бит арифметика, а то и 48 (не помню я сколько там у хайтеха бит для float и double)...
про код алона - ну, ты сам то его смотрел? много там чего понял? формулу/метод его раскусил? а метод у него не документированный, не по permadi/Ширу и даже не по Lodev`у. Что-то своё там...
Sayman, список стен вполне себе по Ширу
горизонтальные/вертикальные.
то как он луч пускает тоже вполне себе понятно.
в край можно просто забрать метод запуска лучей