Лучше в виде конкурса всё делать, конкурс на лучший 3D шутер. Сумма наверно должна быть по крайней мере не меньше чем призовой фонд RGB-2014.Цитата:
Сообщение от SaNchez
Вид для печати
Лучше в виде конкурса всё делать, конкурс на лучший 3D шутер. Сумма наверно должна быть по крайней мере не меньше чем призовой фонд RGB-2014.Цитата:
Сообщение от SaNchez
ZX_NOVOSIB, 3д Шутер на спек? ты наверное шутишь
даже при 8 фпс он не будет динамичным.
я бы рекомендовал РПГ или чтото подобное не слишком ориентированное на реакцию.
а кроме тото что не делай - получится Wolf3d
Ну мне не нужен, например. Никогда не любил шутаны и так и не прошел ни одного. А вот от RPG я бы не отказался, да и сделать ее попроще будет, чем шутан. Только она будет вся некрасивая чернобелая, тухлая в общем, лучше уж пошаговая, зато цветная.Цитата:
Сообщение от SaNchez
С турбой на 14МГц будет поболее восьми.Цитата:
Сообщение от jerri
я ошибся - размер текстуры 64*64.
---------- Post added at 22:55 ---------- Previous post was at 22:53 ----------
ну как тут сделаешь цветную? цветную можно вон на Эво, классик тут какбы мимо кассы.Цитата:
Сообщение от Shadow Maker
Ну хотя бы как в думе от ДР. Углы поворота урезать. Еще чего-нибудь.Цитата:
Сообщение от jerri
Вообщем больше разговоров, чем дела. Перевести исходники на сжасм не деле вопрос одного вечера.
Вложение 54776
Дубль
Макрос RAY раскрыт
Автогенерация таблиц при компиляции переписана на Lua
на самом деле макрос не нужно было раскрывать. версия выше прикреплённая с этим макросом прекрасно справляется. хотя вот для jerri и Destr`а оно будет полезным, наверное.
У меня же пока совсем другие вопросы. Например, есть два основных материала по теме рейкаста:
1. http://zxpress.ru/article.php?id=8482 (тут просто читаемость лучше, чем на zxdn)
2. http://permadi.com/1996/05/ray-casti...e-of-contents/
собственно говоря, первый составлен на основе второго. при этом есть ещё и:
3. http://lodev.org/cgtutor/raycasting.html
подходы в них кажутся разными и в то же время одинаковыми. Если следовать материалам permadi, то там многовато процедур получается, не факт что быстро. Но при этом, я встал на теме синусов и тангенсов. Да да, в школе я часто прогуливал уроки... Во всех материалах требуется работа с float/double. допустим, я напилил табличку тангенсов (для Xa=64/tan(угол луча) ):
табличка с данными в 16 бит (не страшно). А вот что с этими данными дальше делать, если всё и везде float?Код:fprintf(out, "\n\n\nTan256Table:\n");
for(k = 0; k <= 180; k++) {
if((k % 8) == 0) fprintf(out, "\n dw ");
else fprintf(out, ",");
temp = 64 / fabs(tan(k * (PI / 180)));
fprintf(out, "%5.0d", (int)temp);
}
О!!! Крутяк!!!
Использовать fixed point. Например: 192 * sin (45°) = 192 * sin(45/360 * pi) = 192 * sin(32/256 * pi) = 192 * 0,70710678118654752440084436210485 = 192 * 256 * SIN_TABLE[32] / 256 = high(192 * 181) = 135 c точностью 1 (136 с точностью 0,5, если сделать округление по старшему биту млпдшего байта) Точка сдвигается на 8 бит делением на 256: xxxxxxxxxxxxxxxx => xxxxxxxx.xxxxxxxx. Точку не обязательно двигать именно на 8 бит, можно и на больше, можно и на меньше, можно и вправо для больших чисел, можно вообще для разных этапов расчета двигать в разное место. Скажем, если делать вывод по высоте в 2/3 экрана (128 точек), то 7-битной таблицы для расчета по Y будет вполне достаточно, а 7-битное умножение более, чем на 1/8 дешевле 8-битного (за вычетом 4-х тактов на add a,a) с той же точностью в данном случае.Цитата:
Сообщение от Sayman
Alex Rider, выйди в аську...
- - - Добавлено - - -
ну и что, народ теперь кинеца кодить вольфы на zx?))
- - - Добавлено - - -
ещё вот исходник рейкаста для z80
http://www.ticalc.org/pub/86/asm/games/maze3d.zip
а зачем вольфы? если вольф только один был есть и будет.Цитата:
Сообщение от Sayman
смысла в других просто нет
а вот использовать движок для
чего то более другого можно и нужно.
он не для спека жеЦитата:
и разрешение экрана мелкое
jerri, говоря про кинеца кодить вольфы, я имел ввиду то, что кодить игры от первого лица, будто шутеры или рпг или ещё что.
я пересмотрел парочку движков от калькуляторов. разрешение тут не причём. в одном движке используются вызовы системы (синусы, тангенсы, рисовалки на экран) которые, если я верно понял, на бейсике (подобие наших бейсиков 48 и 128). преимуществ по скорости там нет совсем. Мелкое разрешение нивелируется медленными вызовами, расчётами и выводом на этот мелкий экран. Во втором, что по ссылке выше, там чуть более оптимально. Однако, я заколебался реально приводить в пример все прошлые рейкастинг подобные решения для Спектрума - демка дума, демка цитадели, воль2004, вольф48к и все они куда навороченнее, чем решения (движки) под калькуляторы.Цитата:
он не для спека же
и разрешение экрана мелкое
Особенно они выглядят интересными и вкусными, если отойти от темы 3.5мгц, а использовать различные доступные на разных клонах турбо режимы. У меня на моём реале (спринтер) проблем с тормозами нет ни в одном из движков!
Кроме того, чтобы использовать движок вольфа48к надо бы знать его начинку. Я так понимаю, кроме автора про его начинку никто ничего не знает. Допиливать его тут вряд ли кто станет (двери, спрайты, боты, потолок, пол и т.д.).
Я вот в нём не смогу разораться. Мне будет проще (и лучше) разобраться в самой теме рейкастинга и накидать что-то своё. Да, буду это делать долго, что поделать...
Там исходников 50кб всего, было бы желание.Цитата:
Сообщение от Sayman
Писать с нуля сильно сомневаюсь что будет проще.
все чего-то молчат по сабжу - или всем пофиг или все активно кодят свои движки?))))
ладно. вопрос на засыпку: в мануале от Ширу есть такой пунктик:
так вот. изначально я попёрся по второму варианту. Синус и косинус в табличках. Соответсвтенно 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, список стен вполне себе по Ширу
горизонтальные/вертикальные.
то как он луч пускает тоже вполне себе понятно.
в край можно просто забрать метод запуска лучей
интересно, хоть кто-то занялся данной темой?Цитата:
Сообщение от Sayman
ну, Jerri кажется что-то делал, кайдзю, если не ошибаюсь. И с движком Алоновским, он кажется разобрался...Цитата:
Сообщение от LW
делал, делал.Цитата:
Сообщение от Sayman
Алоновский движок так и не дописан.
спрайтов мало, с цветом тоже проблемы.
его движок заточен под 48кб. вроде нет запрета на приминение его к 128кб и более. хотя управление памятью, видимо. прикрутить придётся.Цитата:
Сообщение от jerri
с другой стороны, есть же версия этого же движка с адаптацией под "АТМ3" (zxevo baseconf).
тогда и спрайтов побольше натолкать можно, да и цветов побольше, чем 2.
мне атм3 не интересен.Цитата:
Сообщение от Sayman
а остальное там уж больно захардкожено
без комментов, без описаний и тд итп
раскапывать нет времени сейчас. как появится буду продолжать
про время понятно, а вот про АТМ3, странно, ведь ты же пользуешься ТС конфой, а они там не шибко то далеко друг от друга...Цитата:
Сообщение от jerri
ну я бы сказал - рядом не валялись. разная идеологияЦитата:
Сообщение от Sayman
на ТСконфе я могу ни одного байта напрямую в экранную область не заслать, а изображение будет
на АТМ конечно это не так.