Open Source эмуль...

[SMT]

Наверно, для эмулятора важно, но, напр., для написания игр -- не особо... всё равно 90% времени DirectX работает...

который на VC написан

Я понимаю. А векторные игры типа Elite вообще не переделаешь так.

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

Насчёт "с эмулятором-без эмулятора" -- не так ведь сложно сделать версию "всё в одном". Пользователь получает exeшник, который работает как обычная программа. Но на самом деле это эмулятор с игрой... Прецеденты мне известны.

тогда можно. если тем более эмулятор переделать, выкинуть "эмуляторские" кнопки типа reset

Я думал над этим. Но...
1) это ведь ещё более серьёзная нагрузка на процессор?

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

2) а так ли легко найти спрайт, если он с кем-то на экране столкнулся? или, ещё хуже, по XOR наложен на фон?

да, с затиранием одного спрайта другим - проблема.
а при XOR спек256 что делает? цвета ксорит?

у меня не очень большой опыт в поиске спрайтов, но немного поигрался. Вроде бы в очень многих играх спрайты хранятся в открытом виде: первая строка, потом какое-то смещение, вторая строка и так далее...

Если спрайт лежит так, то его можно спокойно найти (и заменить) в автоматическом режиме..

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

а если спрайты пакованные (хоть RLE), то работа по переводу сильно замедляется

если брать за основу unreal, то редактор лучше загружать в виде dll на delphi/BCB - застрелишься писать на winapi

да, собственно, мне-то какая разница. тебе мучаться...

[rg_software]

да, с затиранием одного спрайта другим - проблема.

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

а при XOR спек256 что делает? цвета ксорит?

Спек256 -- не знаю. А у Кладова предусмотрена специальная опция... Я не вдавался в подробности, но можно где-то прописать, что данная игра использует ксор, и тогда спрайты выводятся особым образом...

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

да мне это нравится! вот только как искать эти спрайты на экране... подумать надо.

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

вот спрайт, летящий по фону -- это на порядок хуже, прямо скажем.

[SMT]

да, делай как собирался. ещё одна проблема - это когда объект "взрывается" - пиксели разлетаются во все стороны проходят поверх спрайтов

[Shaos]

Вообще говоря, я не против дотнета, но это другая история...

Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:

1) прилично организованной модульности и средств абстракции данных (классов то бишь)
2) хорошей и удобной библиотеки, прежде всего, контейнеров (C++ STL)
3) нормально организованной обработки ошибок (try/catch)

да чего углубляться в детали, и так всё ясно... С++ же не от нечего делать создавали...

Чушь какая. Извини за прямоту сишника с 13-летним стажем

Модульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру. STL не стоит возводить на пъедестал лекарства от всех болезней - от кривых программистских ручек он не спасет. По поводу исключений - это припарка на больную голову программистов-чайников

Си будет жить вечно - Дельфи же умрет еще раньше ассемблера для Z80

[rg_software]

да, делай как собирался. ещё одна проблема - это когда объект "взрывается" - пиксели разлетаются во все стороны проходят поверх спрайтов

я вот как раз решил, что оба варианта интересны
как раз ограниченный подход с поиском спрайтов может помочь обойтись малой кровью в случае игр типа I, Ball 2...

[rg_software]

Чушь какая. Извини за прямоту сишника с 13-летним стажем

Вот, видимо, стаж и давит
Мб, у меня своя ностальгия по Spectrum-бейсику...

одульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру.

"Модульность" -- это не свойство языка, а свойство программы. Хорошо структурированную программу и на ассемблере написать можно. Но если язык напрямую поддерживает ОО-парадигму, то жизнь становится гораздо легче...

К примеру, мне приходилось работать со многими C++ и Java-программами. Так вот, хотя С++ поддерживает ООП ничуть не хуже, модульность С++ программ оказывается обычно на порядок слабее, т.к. С++ не заставляет программистов думать об этом...

STL не стоит возводить на пъедестал лекарства от всех болезней - от кривых программистских ручек он не спасет.

STL -- всего лишь инструмент. Который лучше иметь, чем не иметь...

Си будет жить вечно - Дельфи же умрет еще раньше ассемблера для Z80

Да ладно... я сам писал на Си, пусть не 13, но 8 лет точно; и язык этот весьма хорош. Многие вещи в С вызывают слюноотделение у гурманов-извращенцев, но выглядят полными анахронизмами... "хаками", которые затрудняют отладку и разработку...

Чего только стоит пример, когда человек описывает глобальную переменную в одном модуле переменную как int, а в другом -- как extern float; этот код компилируется (!) т.к. линковка идёт по именам без проверки типов (в стандартном С)... естественно, в первом модуле все инструкции генерируются для целых, во втором -- для вещественных чисел, и программа глючит по-страшному...

Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает -- меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые

[Shaos]

К примеру, мне приходилось работать со многими C++ и Java-программами. Так вот, хотя С++ поддерживает ООП ничуть не хуже, модульность С++ программ оказывается обычно на порядок слабее, т.к. С++ не заставляет программистов думать об этом...

Если речь зашла о Java то я могу сказать что сейчас это самое лучшее средство разработки сложных ООП-систем в основном из-за блокировок от дурака на уровне компилятора а также из-за развитой библиотеки классов - очень возможно что Java переживет Си++ в той или иной своей реинкарнации

Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает -- меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые

Все так, но Си - вечен

[Eltaron]

Модульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру.

гы :-)
и будет извращение типа реализации ООП на перле :-))

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

[lvd]

Чего только стоит пример, когда человек описывает глобальную переменную в одном модуле переменную как int, а в другом -- как extern float; этот код компилируется (!) т.к. линковка идёт по именам без проверки типов (в стандартном С)... естественно, в первом модуле все инструкции генерируются для целых, во втором -- для вещественных чисел, и программа глючит по-страшному...

Ну и правильно глючит - если чел идиот, то так ему и надо. Возможно, ты с вершины ООП даже и не в курсе, что флоатные числа на предмет больше-меньше можно СРАВНИВАТЬ целочисленными сравнениями?... слабо так на жабе сделать?

[lvd]

Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает --

Бывает-бывает - у тебя пц на все времена с его ху86 и виндой =)))

меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые

Поправка - не 'меняются', а их 'меняют'. Зачем - надеюсь, не надо объяснять?