SGDK

[MetalliC]

Чет гуано плюсы...

ты случайно не забыл в графе Compiler Options прописать -O2 ? то есть включить оптимизацию, иначе по-умолчанию генерируется "отладочный" код с кучей всякого говнища.

когда я говорил о "С++ подходе" имелось в виду активное использование STL.
к примеру возьмем банальную задачу - сделать функцию суммирующую массив чисел. на С++ это будет выглядеть примерно так:

Код: [Выделить]

#include <vector>
#include <numeric>
int test(std::vector<int> v)
{
    return std::accumulate(v.begin(), v.end(), 0);
}
и не смотря на использование вектора, темплейтов, итераторов, и прочих страшных слов это компилируется (с -O2) в компактный и эффективный код:

Код: [Выделить]

test(std::vector<int, std::allocator<int> >):
        mov     rcx, QWORD PTR [rdi+8]
        mov     rdx, QWORD PTR [rdi]
        xor     eax, eax
        cmp     rdx, rcx
        je      .L4
.L3:
        add     eax, DWORD PTR [rdx]
        add     rdx, 4
        cmp     rcx, rdx
        jne     .L3
        ret
.L4:
        ret
короче аж никак не хуже того, во что скомпилируется C-шное навроде

Код: [Выделить]

int sum;
for (int i = 0; i < xxx; i++)
  sum+= v[i];
return sum;

также, ради интереса можете скомпилировать С++ вариант без оптимизации, чтоб понимать сколько кода было выпилено оптимизатором c -O2.

[worm]

ты случайно не забыл в графе Compiler Options прописать -O2 ? то есть включить оптимизацию, иначе по-умолчанию генерируется "отладочный" код с кучей всякого говнища.

Я не знал о существовании этого флага, спасибо за информацию)

неужели хоть одна умная мысль пытается пробиться в твою голову

тебе показалось

worm, как удобно всех кто фейспалмит от твоих действия обвинять в полыхании   но ты же выучил новое слово и по другому не умеешь, во всех темах где тебя тыкают носом в лужу, ты обвиняешь что у других полыхает 

Как раз таки я признаю свои ошибки, если осознаю это) И не перевожу стрелки, в отличие от некоторых)

[Segaman]

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

[MetalliC]

класс с виртальными методами должен всегда создаваться.

с виртуальными методами не всё просто
https://wikipedia.org/wiki/Таблица виртуальных методов
и не бесплатно, что может быть ощутимо на слабеньких процессорах типа 68000

[ALKOSHA]

Чё там по 3д ? Как показывает демка Овердрайв 2, сижка таки могёт 3д не хуже чем 32х.
В SGDK полный боекомплект процедурок работы с модельно-видовыми матрицами.
Я даже откопал некропост, где питоновый скрипт конвертит OBJ в хедер mesh.h.
Увы, но ссылки ныне мертвы...

Я ж это к чему. Знаете такой люто тормозной, но всё же движок-конструктор https://ru.wikipedia.org/wiki/Freescape ? Так вот. Он обошёл все компы, от ДОСа до амиги. Даже спектрума посетил. А вот сегу обошёл стороной. Хотя у сеги тот же проц, что и у амиги. В чём сложность портировать? Непонятно. Там переделать адресацию пикселей видео-памяти для тру-кодера дело на вечер. Ну да ладно. Я вот мечтаю увидеть подобие этого движка на СМД.

Конечно можно взять за основу уже готовый набор ф-ций SGDK для работы в 3д. Но тут возникают Unreal-ные для меня задачи. Во-первых, реализовать FPS-камеру я вряд ли смогу.
Во-вторых, забивать вручную массив mesh.h - довольно муторное занятие (один лишь кубик выходит довольно громоздким, пока распишешь каждый вертекс, каждую грань, каждую нормаль), без конвертера из распространённых форматов - никак. В-третьих, коллизии - тоже штука колдовская для меня.

Поэтому хотел бы начать с малого. Сделать хотя бы однокомнатный сектор, хотя бы с игнорированием сдвига перспективы по высоте.

Входные данные - набор точек XY рёбер на карте. Высота потолка сектора. XY угол поворота камеры.
Как на основе этих данных расставить отрезки на проекции ? В идеале бы ещё отсечение бэкфейсов сделать. Тут, скорее всего, для каждого отрезка на 2д-карте надо ещё направление нормали указывать.

[SeregaZ]

а ты в дискорде сгдк поспрашивай у буржуев. там вроде чото они трындят, активные короче

[Sharpnull]

Я даже откопал некропост, где питоновый скрипт конвертит OBJ в хедер mesh.h.
Увы, но ссылки ныне мертвы...

Вы о 3D format conversion? Здесь нажимаете Download.
--------
А Overdrive 2 не показатель возможностей игры, там же катсцена, для реальной игры нужны ещё вычисления столкновений и прочего.
Проще сделать пошаговую как Might and Magic или Doom RPG, но у вас цель, полагаю, сделать не игру, а техническую демку.

[ALKOSHA]

как Might and Magic или Doom RPG

Если первое сделано банальным набором картинок, что элементарно, то ДумРПГ как раз процедурными искажениями текстур (не то рейкастинг, не то афинные преобразования по типу Зеро-толераста/Бладшота).

Я прост хотел малость вникнуть в полигональный графон на сеге. Для начала хотя бы проволочный (с отсечением невидимых линий).

Добавлено позже:

Вы о 3D format conversion? Здесь нажимаете Download.

Да, оно... А чёрт! Проклятый гугель! Снова 403-ья ошибка. Это значит сцанкции на крым. Опять ВПН расчехлять!
*ругается по-крымски*

[megavolt85]

Снова 403-ья ошибка. Это значит сцанкции на крым. Опять ВПН расчехлять!

попробуй отсюда

[Ogr]

Как показывает демка Овердрайв 2, сижка таки могёт 3д не хуже чем 32х.

ну да, а если эти 10 полигонов обтянуть текстурами как на 32х, 15фпс на "сижке" превратятся в 5фпс, если не меньше.

[ALKOSHA]

15фпс на "сижке" превратятся в 5фпс, если не меньше

Та не. Так 15-тью фпс-ами и останутся. Ведь для сеги сложнее даётся именно своп пикселей из системной памяти в VDP, а не 3д преобразования.
Gasega же скидывал демку текстурированного автомобиля (там правда ещё олд-версия СГДК, поэтому скорость рендеринга послабее. Но всё же 15 фпс, если авто вдали, 10 если разглядывать в упор). Или вспомните LHX attack chopper. Там же пофиг сколько полигонов в кадре. Там фпс полностью зависит от заливки. Один полигон но на весь экран рендерится дольше, чем десяток но вдали.

П.С. 32х ведь в 3д тоже далеко не мастерски справляется. Там, вроде как, нет аппаратной рисовалки поликов. Всё рисуют те два SH софтварно. И в том же Darxide ощутимые просадки. Да и MetalHead довольно слоупочный.

Добавлено позже:

15фпс на "сижке" превратятся в 5фпс, если не меньше.

Так или иначе, но мне было по кайфу даже с 1-0,5 кадрами в секунду бродить в Castle masters или Dark Side на спермуме. А ведь там даже текстур нет. Так что 5 фпс для квеста такого рода тоже гуд. Особенно когда в наличии текстуры.

П.П.С.П.  на амиге в выше упомянутых игорях и без текстурирования фпс в районе 5-ти. И никто не жаловался.

[Segaman]

Вот если б людям еще понимание того, в каком виде предстает С код скомпиленный в ассемблерный.
А то пишут, вместо шаблонов проектирования, "if"-ы\"else if"-ы, а потом удивляются, почему у них все лагает, а у других нет.

А по движку вашему скажу, что там добрую долю придется переписать, потому что в отличии от амиги, рисующей пикселями, сежка рисует тайлами по 8*8 4bpp и иначе никак. А значит чтобы добраться до планки в 15 фпс, надо еще пропотеть с отрисовкой пикселей внутри тайловой сетки. Простым перенаправлением пикселей тут необойдешься, потому что так можно потратить кучу процессорных тактов впустую на ненужные математические расчеты. Надо именно в двигло писать.

Добавлено позже:
и вариант с blast processing тоже не катит, потому что это драгоценные такты

[ALKOSHA]

А значит чтобы добраться до планки в 15 фпс, надо еще пропотеть с отрисовкой пикселей внутри тайловой сетки

Зачем потеть, когда уже есть готовая СДК с набором ф-ций векторной рисовалки?
Там и точку можно вывести, и линию, и даже закрашенный полигон. И всё это дело шлёпается на экран как раз в пределах 15-20 фпс. Последняя версия недо-вульфа работает в среднем 18 кадров. Далеко не каждый фёрст пёрсон шутан на Амиге (OCS чипсет) такое мог себе позволить, да при таком-то разрешении.

Добавлено позже:
Для меня ныне актуальнее вопрос не то, как оно на уровне асмовых подпрограмм гоняется по тайлам.
А то, как рассчитать точки пространстве, чтоб нарисовать для начала банальный сектор (одну комнату).

[MetalliC]

32х ведь в 3д тоже далеко не мастерски справляется. Там, вроде как, нет аппаратной рисовалки поликов. Всё рисуют те два SH софтварно.

современные видеокарты тоже являются процессорами которые что-то там считают и рисуют софтварно, многие старые тоже, правда не на SH, у той же сеги 3Д-видео нескольких старых аркад было на кучке Fujitsu "TGP" DSP процессоров.

[MetalliC]

Далеко не каждый фёрст пёрсон шутан на Амиге (OCS чипсет) такое мог себе позволить, да при таком-то разрешении.

на амиге своих проблем хватает.
нетекстурированные полигоны там обычно рисовали Blitter-сопроцессором, который делит таймслоты доступа к памяти с Моторолой, и если рисуется много - центральный процессор может здорово тормозиться (раза в два, а может и больше), который в это время обычно не отдыхает а считает геометрию. ну либо наоборот, можно сделать чтоб блиттинг замедлялся, если иначе настроить приоритет доступа к памяти.

если говорить о играх с текстурами - там всё намного хуже, из-за битплановой структуры экрана. рендер или конверсия многоцветного битмапа в битпланы (т.н. chunky-to-planar) занимает существенно времени даже на процессорах типа 68030 или 040, не говоря уже о дохлом 68000.

[ALKOSHA]

современные видеокарты тоже являются процессорами которые что-то там считают и рисуют софтварно

Но в них встроены узкоспециализированные сопроцессора, которые только под графон и заточены, если не брать в расчёт всякие Cuda, DirectCompute и прочее подобное.
А SH процессора ведь универсальные. Они и песню спеть смогут, даже рассчитать траекторию полёта ракеты в космос. Всё зависит от софта.
Но чаще эту насадку юзали лишь как ЦАП для увеличения палитры, и за всё отдувалась старушка 68к по-старинке.

[MetalliC]

Но в них встроены узкоспециализированные сопроцессора, которые только под графон и заточены

кто тебе такое сказал ? у современных видях вполне обычный ISA (набор команд), делать на них можно что-угодно, но да, имеется немало специализированных команд типа векторных произведений, нормализации векторов, или там интерполяции нескольких значений (при текстурной выборке с фильтрацией), и естественно это всё крутится параллельно в кучу потоков.
но в общем и в целом - GPU являются вполне типичными RISC процессорами, ну или VLIW если вспомнить еще и старые ATI.

[ALKOSHA]

GPU являются вполне типичными RISC процессорами,

Это я знаю. Мне просто непонятно, как из данного "чёрного ящика" извлечь готовые вычисления, кроме отображения оных на экране в виде графона.
Неужто можно юзать как FPU, скажем, ту же вуду 3дфх, в которой только растеризатор трианглов, и нет даже T&L чипов ? Не совсем современное правда. Но так, для абстракции примера. А то в нынешних видяхах чего только не накрутили.

[MetalliC]

Мне просто непонятно, как из данного "чёрного ящика" извлечь готовые вычисления, кроме отображения оных на экране в виде графона. Неужто можно юзать как FPU

еще раз - видеокарта это процессор, который бежит про своей программе, читает какие-то данные из памяти, обсчитывает их как-то, и кладет результаты куда-то в память. которую можно читать или писать центральным процессором.
если ты через какой-то 3D-API даешь команду чо-то там нарисовать - драйвера генерируют машинный код этой функции/операции, кладут его в память видяхи, и отправляют на исполнение. то есть по сути, дрова являются таким себе генератором машинного кода.

ту же вуду 3дфх, в которой только растеризатор трианглов, и нет даже T&L чипов ?

оно там по-кругу пошло - раннее 3д-видео было построено на вполне обычных процессорах или DSP, потом стали использовать специализированые fixed-function ASIC-и (типа как 3дфх), а потом всё вернулось взад к процессорам и "софтовому" рендерингу.

[ALKOSHA]

раннее 3д-видео было построено на вполне обычных процессорах

Смотря насколько раннее... Аркадные автоматы Hard drivin на двух моторолах?
Или же 3DO-шки с Плюйстейшонами ?

[MetalliC]

Смотря насколько раннее... Аркадные автоматы Hard drivin на двух моторолах?

да, я про них.
в Hard drivin емнип всё рисует и считает ADSP-2100
в Sega Model1 / Model2 - кучка TGP DSP
в Namco System22 тоже вроде десяток или два каких-то DSP процессоров.

[Томахомэ]

в Namco System22 тоже вроде десяток или два каких-то DSP процессоров.

Непосредственно DSP там только 2 - оба TMS320C25, один отвечает за обработку геометрии, другой - за освещение. А вот уж чего там реально десяток, так это мелких кастомных чипчиков, каждый из которых отвечает за что-то своё: один - за тайлмэпы текствого слоя, другой - за гамма-коррекцию, третий - за прозрачность, и т. д. Многие из них, что интересно, вполедствии уже в Namco System 23 были использованы.

В Sega Model 1, кстати, TGP был только один, и в самом первом варианте Model 2 - тоже.

[MetalliC]

В Sega Model 1, кстати, TGP был только один, и в самом первом варианте Model 2 - тоже.

кто тебе такое сказал ? в модели1 стоят 5 штук TGP (Fujitsu MB86233), но естественно они так не маркируются, на них написано Sega 315-5571 315-5572 итп шоб враги не догадались.

то же касается и Namco System 22 - многие из "кастомных" чипов с маркировкой типа "Namco C123" являются off-shelf DSP или процессорами, и они там совсем не маленькие - по 160 или 208 ног.

[Segaman]

ALKOSHA, просто запомни мои слова, что проц не вывезет твоих амбиций
Си-шный компиль под сегу весьма плохо оптимизирует код.
И до вас чо-то совсем недоходит моя молва про прорисовку точек внутри тайлов.
Да там даже не точки, а квадраты 2*1, иначе вместо 15 фпс можно получить 2 с половиной.
Вместо пустых слов про то, какие эти движки отличные, сначала попробуйте их засунуть, а потом говорите о возможностях всего этого дела на сеге. 
Говорить об грядущем успехе каждый горазд, зато падать в грязь лицом - "наши полномочия здесь всё"

[ALKOSHA]

Да там даже не точки, а квадраты 2*1, иначе вместо 15 фпс можно получить 2 с половиной.

Кееееееееп)))))

А что из сказанного мною не соответствует действительности? К чему конкретно придирки?

Добавлено позже:

что проц не вывезет твоих амбиций

Фрискейп энжин пахал даже на спектруме.
1 фпс но пахал же. А ведь там и процык в несколько раз слабее. Да и адресное пространство видео-памяти нелинейно, так что тоже на конвертацию SetPixel XY тратятся драгоценные  такты.



Добавлено позже:

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

Этим и собирался заняться. Но пока на раб(оте) нахожусь.
Между тем возникло несколько вопросов, как у не совсем уверенного пользователя ПК.
Вот для того питонового скрипта любой ведь интерпретатор питона можно скачать, после чего открыть CMD, указать путь к piton.exe, а далее приписать obj2mesh.py -f afile.obj > meshs.h ?
Где afile.obj моя кастомная моделька.
И что если кол-во вершин более 256? Там типа мульти-конвертацию добавили. Это ж можно разбить на сегменты?

[ALKOSHA]

Си-шный компиль под сегу весьма плохо оптимизирует код.
И до вас чо-то совсем недоходит моя молва про прорисовку точек внутри тайлов.

Процедурки рисования на асме, разве не?

В демках полигонастые модели рендерятся 20 фпс.

10 фпс это когда уже доходит до текстурирования И ТО (!) на старой версии СДК, где своп был менее шустрым.

С моей же стороны достаточно лишь загнать контент в сишный массив. Сделать FPS камеру, и коллизии. Всё самое сложное уже сделали за меня.
И к чему эти басни про то что Сега чё-то там не сможет? Не от сеги всё зависит. А от разработчика.

Добавлено позже:
Поставил питона. Создал в каталоге с obj-ем батник.

Код: [Выделить]

obj2mesh.py -f dd2.obj > meshs.h
pause
Запускаю с правами админа, и...


Чё оно такое?

[SeregaZ]

русский буква там в пути смотри ???? возможно в этом дело. попробуй путь буржуйскими написать.

[ALKOSHA]

Убрал в пути кириллицу, всё равно бестолку, та же ошыбка 

[megavolt85]

попробуй без батника и не перенаправляй stdout

скорей всего увидишь ошибку типа

Код: [Выделить]

Traceback (most recent call last):
  File "obj2mesh.py", line 4, in <module>
    import numpy
ImportError: No module named numpy
ну а там дело техники, pip install numpy и будет тебе счастье

[SeregaZ]

так ты в двух местах правил? то есть сам путь на жестком диске без кириллицы и уже потом в батнике тоже без кириллицы?