Просмотр полной версии : Open Source эмуль...
rg_software
04.03.2005, 17:09
Посоветуйте, пожалуйста, хороший современный сабж для экспериментов (под Windows)!
Из того, что пробовал, пока более-менее удовлетворил DelphiSpec, но там свои проблемы...
А так -- большинство проектов недоработаны, либо кучи доп. библиотек требуют (пока скомпилишь, проклянёшь всё на свете), либо написаны настолько криво, что к коде чёрт ногу сломит...
FUSE.
прекрасный проэкт, хороший код и много возможностей.
rg_software
04.03.2005, 18:01
FUSE. прекрасный проэкт, хороший код и много возможностей.
"Fuse - the Free Unix Spectrum Emulator"?
Во-первых, Уних, а это значит, что для портирования под винду повозиться всё-таки придётся...
Во-вторых, при всём уважении, эти ребята юзают чистый С, что в наше время мне кажется, мягко говоря, странным... У меня нет предубеждений против этого эмулятора, но, боюсь, я трижды подумаю, прежде чем лезть модифицировать этот код :)
С точки зрения кода мне нравятся Jasper и JXZ, но они слишком ограничены, да и на Java... Я бы предпочёл С++ всё-таки :)
на какой язык ориентируешься?
Я бы предпочёл С++ всё-таки :)
c++ - unreal speccy
rg_software
04.03.2005, 18:13
c++ - unreal speccy
а разве он опен сорс?
если да, где лежит :D
Во-вторых, при всём уважении, эти ребята юзают чистый С, что в наше время мне кажется, мягко говоря, странным...
Вот тут поясни плиз! Почему это тебе странным кажется? А если бы юзали c# или dotНЕТУ, это видимо в самый раз для тебя было бы?... =)
rg_software
04.03.2005, 19:21
Вот тут поясни плиз! Почему это тебе странным кажется? А если бы юзали c# или dotНЕТУ, это видимо в самый раз для тебя было бы?... =)
Вообще говоря, я не против дотнета, но это другая история...
Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:
1) прилично организованной модульности и средств абстракции данных (классов то бишь)
2) хорошей и удобной библиотеки, прежде всего, контейнеров (C++ STL)
3) нормально организованной обработки ошибок (try/catch)
да чего углубляться в детали, и так всё ясно... С++ же не от нечего делать создавали...
Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:
1) прилично организованной модульности и средств абстракции данных (классов то бишь)
2) хорошей и удобной библиотеки, прежде всего, контейнеров (C++ STL)
3) нормально организованной обработки ошибок (try/catch)
да чего углубляться в детали, и так всё ясно... С++ же не от нечего делать создавали...
Угу, не от нечего делать создавали и винды всякие, и жабу, и пни, на СВЧ-частотах работающие, винты в 200Гб и т.д. Скоро программы будут писать, наговаривая в микрофон, что от программы хочется, а средний размер программы типа 'открой окно с надписью хелл оф ворлд' будет гига 2. А человек, умеющий грамотно артикулировать, чтоб его комп таким манером понял, будет считаться классным программистом. Если тебе туда - то мне с тобой не по пути...
rg_software
04.03.2005, 21:02
Угу, не от нечего делать создавали и винды всякие, и жабу, и пни, на СВЧ-частотах работающие, винты в 200Гб и т.д. Скоро программы будут писать, наговаривая в микрофон, что от программы хочется, а средний размер программы типа 'открой окно с надписью хелл оф ворлд' будет гига 2. А человек, умеющий грамотно артикулировать, чтоб его комп таким манером понял, будет считаться классным программистом. Если тебе туда - то мне с тобой не по пути...
Ладно, не надо передёргивать...
Даже если все вокруг будут писать таким манером, тебя никто не лишает языка С и прочего :)
Если уж на то пошло, то зачем компромиссы? Компьютеры с сороковых существуют, а С только в 78м придумали или около того. Пиши на машинном коде. Или на фортране. В крайнем случае, на алголе, а уж С -- это слишком современно :)
а разве он опен сорс?
если да, где лежит :D
исходник всегда распространяется с бинарником:
http://trd.speccy.cz/emulz/US027B.ZIP
написано, правда, не в лучшем стиле. но если бы я серъёзно занимался архитектурой, то никогда бы его не выпустил (что подтверждается ещё парой моих проектов, которые я похоже вечно буду переписывать). но потихоньку перевожу эмуляцию устройств или в отдельные классы, или в передачу указателя на структуру устройства во все функции работы с ним (что оно и то же). в следующей версии планирую ВГ93 оформить в класс.
в-общем, идеальный open-source эмулятор - это понятный код, независимость от посторонних библиотек и богатые функциональные возможности. а реальный... выберите любые два пункта :)
rg_software
04.03.2005, 21:25
исходник всегда распространяется с бинарником:
http://trd.speccy.cz/emulz/US027B.ZIP
Окей, спасибо. Надеюсь, руки дойдут до интересующих вещей...
Как относишься (и другие тоже :) ) к направлению Spec256 и 256-цветному режиму в EmuZWin?
Меня его развитие интересует как раз-таки...
Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С
Есть цели и есть средства их достижения. C++ порождает слишком много "школ" кодописи, и очень неэффективен на малых платформах. Потом есть люди которым вся модная ООП мишура опротивела. Одно дело если ведешь коммерческий проект, и так все по последней моде. Другое дело - программировать в удовольствие.
Мне лично кажется что на мелких платформах чистые процедурные языки - самое то. А на платформах где ресурсы - не проблема, языки очень высокого уровня (т.е. где не надо парится с индексами, указателями и алоцированием/освобождением памяти) гораздо продуктивнее. По мне для бизнес приложений Visual Basic 6, C#, PHP или Java гораздо лучше C++
Как относишься (и другие тоже) к направлению Spec256 и 256-цветному режиму в EmuZWin?
играть в игры становится приятнее. но в железо этот режим перенести нельзя. одно время, очень сильно загонялся по поводу разных видеофильтров в unreal (доходило даже до реализации эффектов из чужих дем - тот же motion blur, потом всё лишнее стёр). так вот, экспериментировал с авто-раскраской спектрумовского экрана в цвета по шаблонам. но результат оказался не очень адекватным, хотя было забавно. есть какие-то свои соображения?
а именно режим Spec256 - imho софта маловато; в эмуляторах эта ниша уже занята.
rg_software
05.03.2005, 11:13
Потом есть люди которым вся модная ООП мишура опротивела.
Да ладно вам... не хотите классов, не юзайте; но пусть мне кто-то докажет, что
int *p = (int)malloc(sizeof(int)*100);
...
free(p);
читается лучше, чем
vector<int> p(100);
и так все по последней моде. Другое дело - программировать в удовольствие.
Так что на моду мне плевать. Научиться писать в стиле ООП правильно куда сложнее, чем в процедурном стиле. Но компьютером тоже овладеть труднее, чем шариковой ручкой; зато и сделать можно больше и эффективнее...
А насчёт эффективности генерируемого кода -- уж тут всё от конкретной программы зависит...
for(i = 0; i < 10; i++)
sum += i;
и в С, и в С++ одинаково быстро работает...
rg_software
05.03.2005, 11:27
есть какие-то свои соображения?
Более чем!
а именно режим Spec256 - imho софта маловато; в эмуляторах эта ниша уже занята.
Уверен, что нет :)
Oх, пытался откомпилировать Унреал... Если он всё равно только на MSVC компилируется, что ж не сделать обычный воркспейс?.. Я понимаю, когда батнички пишут, чтобы на любом компилятере... Ну ладно, это отступление.
Так вот, как известно, сейчас режим 256 поддерживают два эмулятора -- Спек256 и EmuZWin Владимира Кладова. Формат файлов одинаковый. Пара человек занимается раскраской игр:
http://www.arjun.150m.com/ZX256games.html
http://home.earthlink.net/~zx_makeovers/
ну и оригинальные разработки от Спек256:
http://www.emulatronia.com/emusdaqui/spec256/index-eng.htm
Я думаю, что направление перспективное, и почему бы не раскрасить пару-тройку игр? Выглядит это очень приятно!
Что меня не устраивает. 256 цветов -- это здорово, но разрешение 256*192 портит всё впечатление. В спеке256 каждому пикселю сопоставляется один байт, что даёт 256 цветов. Почему бы каждому пикселю не сопоставить ЧЕТЫРЕ байта? 512*384 -- уже куда интереснее. Можно, при желании, сделать и triple screen, но, по своему опыту скажу, что нарисовать приличные спрайты размером в 3 раза больше оригинальных довольно трудно...
А раскрашенные hi-res игры будут выглядеть замечательно... Посмотрите хотя бы на Head over heels remake. Ну или на Joe Blade 3 Remake ;)
Я на эту тему писал Кладову, но он не очень заинтересовался. Среди причин -- непомерные (по его мнению) аппаратные требования такой программы. Хотя мне так не кажется...
Вот я и смотрю, какой бы эмуль можно было бы проще всего "апгрейдить" таким способом :cool:
Более чем!
какие, если не секрет?
Oх, пытался откомпилировать Унреал... Если он всё равно только на MSVC компилируется, что ж не сделать обычный воркспейс?.. Я понимаю, когда батнички пишут, чтобы на любом компилятере...
у msvc уродская среда, слабый редактор. far+плагины - куда более полноценная система. компиляция с командной строки.
Так вот, как известно, сейчас режим 256 поддерживают два эмулятора -- Спек256 и EmuZWin Владимира Кладова. Формат файлов одинаковый. Пара человек занимается раскраской игр:
http://www.arjun.150m.com/ZX256games.html
http://home.earthlink.net/~zx_makeovers/
ну и оригинальные разработки от Спек256:
http://www.emulatronia.com/emusdaqui/spec256/index-eng.htm
Я думаю, что направление перспективное, и почему бы не раскрасить пару-тройку игр? Выглядит это очень приятно!
Что меня не устраивает. 256 цветов -- это здорово, но разрешение 256*192 портит всё впечатление. В спеке256 каждому пикселю сопоставляется один байт, что даёт 256 цветов. Почему бы каждому пикселю не сопоставить ЧЕТЫРЕ байта? 512*384 -- уже куда интереснее. Можно, при желании, сделать и triple screen, но, по своему опыту скажу, что нарисовать приличные спрайты размером в 3 раза больше оригинальных довольно трудно...
А раскрашенные hi-res игры будут выглядеть замечательно... Посмотрите хотя бы на Head over heels remake. Ну или на Joe Blade 3 Remake ;)
Я на эту тему писал Кладову, но он не очень заинтересовался. Среди причин -- непомерные (по его мнению) аппаратные требования такой программы. Хотя мне так не кажется...
Вот я и смотрю, какой бы эмуль можно было бы проще всего "апгрейдить" таким способом :cool:
а, понял. то есть всё-таки не автомат, а ручная переделка игр. тогда мне это не интересно
rg_software
05.03.2005, 20:01
у msvc уродская среда, слабый редактор. far+плагины - куда более полноценная система. компиляция с командной строки.
C++Builder форева несмотря на все минусы :)
а, понял. то есть всё-таки не автомат, а ручная переделка игр. тогда мне это не интересно
Ну... эээ... хехе :)
Конечно, можно возиться сколько влезет с фильтрами и тому подобными вещами, но ведь это в принципе невозможно -- получить алгоритмической раскраской тот же результат, что и при "ручной отделке"... Разве нет?
Идея эта не от фонаря, а из наблюдений. Меня сейчас интересуют в большей степени римейки. Так вот, если посмотреть, то процентов 60-70 из них представляют собой попросту "апгрейд" графики и звука с попыткой полностью сохранить геймплей оригинала.
Оставшиеся действительно пытаюстся придумать что-то новое, сохраняющее дух оригинала (напр., Cyclone 3D или Airburner 3D).
Интересно и первое, и второе направление; да только первое имхо бесперспективно. Люди тратят кучу времени на попытки воссоздать в деталях поведение оригинала. Гораздо лучше было бы посидеть вечерок-другой и перерисовать спрайты, а потом присобачить к эмулятору наподобие спека256. Мне кажется, было бы весьма здорово иметь инструмент для создания штук типа Head over Heels за пару дней...
Но, видимо, не все разделяют мои воззрения... :o
C++Builder форева несмотря на все минусы :)оптимизатор слабый. среда чуть получше, но тоже... (именно текстовый редактор хромает)
Конечно, можно возиться сколько влезет с фильтрами и тому подобными вещами, но ведь это в принципе невозможно -- получить алгоритмической раскраской тот же результат, что и при "ручной отделке"... Разве нет?да, но если есть хоть что-то, оно включается в любой игре
Идея эта не от фонаря, а из наблюдений. Меня сейчас интересуют в большей степени римейки. Так вот, если посмотреть, то процентов 60-70 из них представляют собой попросту "апгрейд" графики и звука с попыткой полностью сохранить геймплей оригинала.
такие игры - штучный товар :) и трудозатрат в них вкладывается очень много... а если фон рисуется не спрайтом, а простыми push/ld, тогда нужно искать места в коде, чтобы заменить аргументы инструкций на hires-аналоги (то есть полноценно раскрасить игру нельзя, просто редактируя спрайты в памяти)
может, лучше делать сразу windows-версии? их хотя бы можно использовать как самостоятельный продукт, без эмулятора.
сейчас ещё вариант придумался. не такой тяжёлый с точки зрения переделки эмулятора. добавить видео-фильтр, который на готовом 6912-экране ищет нужные спрайты и заменяет их на hires (ну как anti-text64 в unreal). естественно, искать с попиксельным скроллером и масками. процесс перевода игры выглядем бы проще: выделяешь спрайт на экране рамкой/контуром, рисуешь/подгружаешь hires. плюсом было бы то, что игра бы хранилась в оригинальном формате, файл спрайтов был бы внешний. спрайты можно организовывать по виртуальным каталогам для удобства. каждый мог бы добавить свои спрайты, заменить часть на другие. а для спек256-игр это всё равно, что провести поиск и разборку с нуля (в расширенной игре не хранятся явно адреса/форматы спрайтов)
rg_software
06.03.2005, 03:34
оптимизатор слабый.
Наверно, для эмулятора важно, но, напр., для написания игр -- не особо... всё равно 90% времени DirectX работает...
такие игры - штучный товар :) и трудозатрат в них вкладывается очень много... а если фон рисуется не спрайтом, а простыми push/ld, тогда нужно искать места в коде
Я понимаю. А векторные игры типа Elite вообще не переделаешь так.
может, лучше делать сразу windows-версии? их хотя бы можно использовать как самостоятельный продукт, без эмулятора.
Смотря что под этим понимать. Если речь идёт о "продвинутом" римейке, далеко отходящем от оригинала, согласен... Но если только переделать спрайты... не, ну не такие уж трудозатраты! Спрайты можно найти полуавтоматически (сам пробовал)...
Вон жду уже хз сколько приличных Exolon и I, Ball II... не первый год проекты в разработке...
Насчёт "с эмулятором-без эмулятора" -- не так ведь сложно сделать версию "всё в одном". Пользователь получает exeшник, который работает как обычная программа. Но на самом деле это эмулятор с игрой... Прецеденты мне известны.
сейчас ещё вариант придумался. не такой тяжёлый с точки зрения переделки эмулятора. добавить видео-фильтр, который на готовом 6912-экране ищет нужные спрайты и заменяет их на hires
Я думал над этим. Но...
1) это ведь ещё более серьёзная нагрузка на процессор?
2) а так ли легко найти спрайт, если он с кем-то на экране столкнулся? или, ещё хуже, по XOR наложен на фон?
для спек256-игр это всё равно, что провести поиск и разборку с нуля (в расширенной игре не хранятся явно адреса/форматы спрайтов)
у меня не очень большой опыт в поиске спрайтов, но немного поигрался. Вроде бы в очень многих играх спрайты хранятся в открытом виде: первая строка, потом какое-то смещение, вторая строка и так далее...
Если спрайт лежит так, то его можно спокойно найти (и заменить) в автоматическом режиме..
Наверно, для эмулятора важно, но, напр., для написания игр -- не особо... всё равно 90% времени DirectX работает...
который на VC написан :)
Я понимаю. А векторные игры типа Elite вообще не переделаешь так.
хотя бы приборы, линии, окружности и круги можно в разные цвета покрасить...
Насчёт "с эмулятором-без эмулятора" -- не так ведь сложно сделать версию "всё в одном". Пользователь получает exeшник, который работает как обычная программа. Но на самом деле это эмулятор с игрой... Прецеденты мне известны.
тогда можно. если тем более эмулятор переделать, выкинуть "эмуляторские" кнопки типа reset
Я думал над этим. Но...
1) это ведь ещё более серьёзная нагрузка на процессор?
смотря как реализовывать, можно и деревья поиска организовать, можно и для каждого набора спрайтов генерить оптимизированный x86-код поиска. твой вариант - это просто вместо каждого бита пересылать 33 бита - тоже нагрузка
2) а так ли легко найти спрайт, если он с кем-то на экране столкнулся? или, ещё хуже, по XOR наложен на фон?
да, с затиранием одного спрайта другим - проблема.
а при XOR спек256 что делает? цвета ксорит?
у меня не очень большой опыт в поиске спрайтов, но немного поигрался. Вроде бы в очень многих играх спрайты хранятся в открытом виде: первая строка, потом какое-то смещение, вторая строка и так далее...
Если спрайт лежит так, то его можно спокойно найти (и заменить) в автоматическом режиме..
у моего предложения тоже есть преимущества - можно создавать библиотеки спрайтов. например, для dizzy. и использовать его в любой части, даже если части на разных движках. не нужно снова искать его, где и как он хранится в памяти.
а если спрайты пакованные (хоть RLE), то работа по переводу сильно замедляется
если брать за основу unreal, то редактор лучше загружать в виде dll на delphi/BCB - застрелишься писать на winapi
да, собственно, мне-то какая разница. тебе мучаться...
rg_software
06.03.2005, 04:38
да, с затиранием одного спрайта другим - проблема.
...которая меня больше всего и беспокоит :)
Понятно, что даже самый навороченный фильтр прикрутить проще, чем создавать параллельную эмуляцию чего-нить ещё...
а при XOR спек256 что делает? цвета ксорит?
Спек256 -- не знаю. А у Кладова предусмотрена специальная опция... Я не вдавался в подробности, но можно где-то прописать, что данная игра использует ксор, и тогда спрайты выводятся особым образом...
у моего предложения тоже есть преимущества - можно создавать библиотеки спрайтов. например, для dizzy. и использовать его в любой части, даже если части на разных движках.
да мне это нравится! вот только как искать эти спрайты на экране... подумать надо.
мб, столкновение спрайтов не так страшно, если искать по всем четырём углам прямоугольника спрайта. Если хоть одно совпадение найдено -- окей, рисуем спрайт... Какой получится спереди, а какой сзади -- тоже хороший вопрос, но и это можно решить...
вот спрайт, летящий по фону -- это на порядок хуже, прямо скажем.
да, делай как собирался. ещё одна проблема - это когда объект "взрывается" - пиксели разлетаются во все стороны проходят поверх спрайтов
Вообще говоря, я не против дотнета, но это другая история...
Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:
1) прилично организованной модульности и средств абстракции данных (классов то бишь)
2) хорошей и удобной библиотеки, прежде всего, контейнеров (C++ STL)
3) нормально организованной обработки ошибок (try/catch)
да чего углубляться в детали, и так всё ясно... С++ же не от нечего делать создавали...
Чушь какая. Извини за прямоту сишника с 13-летним стажем ;)
Модульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру. STL не стоит возводить на пъедестал лекарства от всех болезней - от кривых программистских ручек он не спасет. По поводу исключений - это припарка на больную голову программистов-чайников :wink:
Си будет жить вечно - Дельфи же умрет еще раньше ассемблера для Z80 :smile:
rg_software
06.03.2005, 11:22
да, делай как собирался. ещё одна проблема - это когда объект "взрывается" - пиксели разлетаются во все стороны проходят поверх спрайтов
я вот как раз решил, что оба варианта интересны :)
как раз ограниченный подход с поиском спрайтов может помочь обойтись малой кровью в случае игр типа I, Ball 2...
rg_software
06.03.2005, 11:32
Чушь какая. Извини за прямоту сишника с 13-летним стажем ;)
Вот, видимо, стаж и давит :D
Мб, у меня своя ностальгия по Spectrum-бейсику...
одульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру.
"Модульность" -- это не свойство языка, а свойство программы. Хорошо структурированную программу и на ассемблере написать можно. Но если язык напрямую поддерживает ОО-парадигму, то жизнь становится гораздо легче...
К примеру, мне приходилось работать со многими C++ и Java-программами. Так вот, хотя С++ поддерживает ООП ничуть не хуже, модульность С++ программ оказывается обычно на порядок слабее, т.к. С++ не заставляет программистов думать об этом...
STL не стоит возводить на пъедестал лекарства от всех болезней - от кривых программистских ручек он не спасет.
STL -- всего лишь инструмент. Который лучше иметь, чем не иметь...
Си будет жить вечно - Дельфи же умрет еще раньше ассемблера для Z80 :smile:
Да ладно... я сам писал на Си, пусть не 13, но 8 лет точно; и язык этот весьма хорош. Многие вещи в С вызывают слюноотделение у гурманов-извращенцев, но выглядят полными анахронизмами... "хаками", которые затрудняют отладку и разработку...
Чего только стоит пример, когда человек описывает глобальную переменную в одном модуле переменную как int, а в другом -- как extern float; этот код компилируется (!) т.к. линковка идёт по именам без проверки типов (в стандартном С)... естественно, в первом модуле все инструкции генерируются для целых, во втором -- для вещественных чисел, и программа глючит по-страшному...
Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает -- меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые :)
К примеру, мне приходилось работать со многими C++ и Java-программами. Так вот, хотя С++ поддерживает ООП ничуть не хуже, модульность С++ программ оказывается обычно на порядок слабее, т.к. С++ не заставляет программистов думать об этом...
Если речь зашла о Java то я могу сказать что сейчас это самое лучшее средство разработки сложных ООП-систем в основном из-за блокировок от дурака на уровне компилятора а также из-за развитой библиотеки классов - очень возможно что Java переживет Си++ в той или иной своей реинкарнации :wink:
Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает -- меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые :)
Все так, но Си - вечен :smile:
Модульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру.
гы :-)
и будет извращение типа реализации ООП на перле :-))
мне вот тоже с++ гораздо ближе, хотя тут, наверное, сыграло свою роль то, что сев за ПЦ только на объектно-ориентированных языках и писал
Чего только стоит пример, когда человек описывает глобальную переменную в одном модуле переменную как int, а в другом -- как extern float; этот код компилируется (!) т.к. линковка идёт по именам без проверки типов (в стандартном С)... естественно, в первом модуле все инструкции генерируются для целых, во втором -- для вещественных чисел, и программа глючит по-страшному...
Ну и правильно глючит - если чел идиот, то так ему и надо. Возможно, ты с вершины ООП даже и не в курсе, что флоатные числа на предмет больше-меньше можно СРАВНИВАТЬ целочисленными сравнениями?... слабо так на жабе сделать?
Неужели язык должен разрешать компиляцию таких ошибочных кусков? Я могу привести ещё кучу примеров, но чего спорить? Разве не понятно, что "чего-то на все времена" не бывает --
Бывает-бывает - у тебя пц на все времена с его ху86 и виндой =)))
меняются парадигмы и взгляды на "джентльменский набор" языка... И сейчас не семидесятые :)
Поправка - не 'меняются', а их 'меняют'. Зачем - надеюсь, не надо объяснять?
rg_software
14.03.2005, 20:18
Ну и правильно глючит - если чел идиот, то так ему и надо. Возможно, ты с вершины ООП даже и не в курсе, что флоатные числа на предмет больше-меньше можно СРАВНИВАТЬ целочисленными сравнениями?... слабо так на жабе сделать?
Ох... Вешать ярлыки -- каждый горазд. Особенно, когда сам не сталкивался с такими вещами. Я могу лишь посоветовать обратиться к литературе, в которой описаны классические ошибки, совершённые программистами мирового класса, и влетевшие в копеечку. Пример с float'ом -- лишь один из них. Другой известный пример -- компиляция фортраном инструкции DO как идентификатора из-за того, что человек случайно поставил точку вместо запятой. Из-за этого при взлёте взорвалась ракета; потеряны были миллионы долларов. Из-за этого, во многом, был разработан язык Ada, в котором все такие штуки сведены к минимуму.
Сравнивать флоаты целочисленно -- непереносимо, потому что на разных архитектурах флоаты могут представляться по-разному.
Поправка - не 'меняются', а их 'меняют'. Зачем - надеюсь, не надо объяснять?
Зачем обиняками выражаться? Не знаю, зачем и не знаю, кто. Все парадигмы, которые сейчас есть, известны ещё с пятидесятых-шестидесятых.
Парадигмы никто не меняет, это процесс объективный. На майкрософт кивать не надо. ООП появилось в Simula 67, но лишь в 90х годах его стали реально юзать. Парадигма была уже давным-давно.
Вообще я сторонник бизнес-подхода. Если некто пишет программу за неделю на С++ с OOП и STL или даже на Visual Basic, а другой на С за месяц, первый куда выгоднее...
Ох... Вешать ярлыки -- каждый горазд. Особенно, когда сам не сталкивался с такими вещами. Я могу лишь посоветовать обратиться к литературе, в которой описаны классические ошибки, совершённые программистами мирового класса, и влетевшие в копеечку. Пример с float'ом -- лишь один из них. Другой известный пример -- компиляция фортраном инструкции DO как идентификатора из-за того, что человек случайно поставил точку вместо запятой. Из-за этого при взлёте взорвалась ракета; потеряны были миллионы долларов. Из-за этого, во многом, был разработан язык Ada, в котором все такие штуки сведены к минимуму.
Ни один язык и метод не гарантирует от ошибок, в том числе и ада, и ооп... дальше что? Не будет одних ошибок, будут другие - и не факт, что их будет легче найти.
Сравнивать флоаты целочисленно -- непереносимо, потому что на разных архитектурах флоаты могут представляться по-разному.
Покуда целые знаковые числа представляются дополненением до 2, а флоаты - по стандарту ИЕЕЕ - можно. Если конечно считать, что это не так - то тогда и биты нельзя анализировать на сях и сдвиги делать (а то вдруг попадётся какая-нить архитектура с троичной, а не двоичной основой?).
Парадигмы никто не меняет, это процесс объективный. На майкрософт кивать не надо. ООП появилось в Simula 67, но лишь в 90х годах его стали реально юзать. Парадигма была уже давным-давно.
Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?
Вообще я сторонник бизнес-подхода. Если некто пишет программу за неделю на С++ с OOП и STL или даже на Visual Basic, а другой на С за месяц, первый куда выгоднее...
Угу, побыстрее наклепать, побыстрее продать, побыстрее забыть, побыстрее забить - в общем, в добрый путь.
Вот только что пока в рамках 'эхотага' такого нету - и слава погу.
rg_software
14.03.2005, 23:17
Ни один язык и метод не гарантирует от ошибок, в том числе и ада, и ооп... дальше что? Не будет одних ошибок, будут другие - и не факт, что их будет легче найти.
Безусловно. Но тех не будет -- и слава богу! Я читал недавно одну книгу по программированию, написанную в 79 году. Так там такие "советы" даются! Это диву даёшься! Мы от них так далеко ушли (в лучшую сторону), что я благодарен судьбе за то, что мне не приходится заниматься той мурой, что занимались предки... 90% всех ошибок, которым уделялось там внимание, решаются благодаря умной организации языка программирования... И нынешние ошибки -- лишь следствие того, что мы хотим большего. В те времена Pacman был сложным коммерческим проектом; сейчас я его за один вечер напишу.
Покуда целые знаковые числа представляются дополненением до 2, а флоаты - по стандарту ИЕЕЕ - можно. Если конечно считать, что это не так - то тогда и биты нельзя анализировать на сях и сдвиги делать (а то вдруг попадётся какая-нить архитектура с троичной, а не двоичной основой?).
Ну хорошо; а почему ты думаешь, что сравнение float'ов в С++ происходит не так? Кто мешает оптимизатору воспользоваться этим фактом?
Кстати, года четыре назад у меня был один удивительный результат. В одной программе я попытался заменить вычисления синусов и косинусов табличными значениями (стандартная оптимизация). Выгоды почти никакой не получилось -- математический сопроцессор и так замечательно считал...
Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?
Нуу... и да, и нет. Я помню, какой был вопль году так в 96-98, что все завтра будут только на Джаве сидеть. Сидят?
Дот-нет, кстати, вещь хорошая. А если Майкрософт реализует аппаратную поддержку (о чём они мечтают), то и по скорости будет не хуже ассемблера. Да и, насколько понимаю, обычные (не дот-нет) приложения никто не отменяет. И уверен, что не отменит.
Угу, побыстрее наклепать, побыстрее продать, побыстрее забыть, побыстрее забить - в общем, в добрый путь.
Вот только что пока в рамках 'эхотага' такого нету - и слава погу.
Да ради бога. Когда ты пишешь для своего удовольствия -- можно юзать ZX Spectrum Basic, чтобы слеза ностальгии прошибала. Может, я тоже чего подобное юзаю, пока никто не видит :)
Но я отказываюсь понимать, когда человек предпочитает копать лопатой, а не экскаватором. И единственная тому причина -- ему влом прочесть мануал по пользованию экскаватором...
Парадигмы тут причём? Я говорю о том, что некрософт всех пересаживает на до-диез и дотНЕТУ, например - ты не согласен?
а почему это плохо? особенно учитывая наличие Mono и dotGNU.
на мой взгляд у MS получилось очень не плохо в плане удобства разработки/скорости работы/etc
Дот-нет, кстати, вещь хорошая. А если Майкрософт реализует аппаратную поддержку (о чём они мечтают), то и по скорости будет не хуже ассемблера. Да и, насколько понимаю, обычные (не дот-нет) приложения никто не отменяет. И уверен, что не отменит.
о как! я что-то пропустил? MS начинает играть на рынке hardware?
rg_software
15.03.2005, 14:09
о как! я что-то пропустил? MS начинает играть на рынке hardware?
Необязательно играть самому, достаточно заключить хороший альянс :)
Пару лет назад я был на одной презентации, где представители M$ и Intel взахлёб признавались в любви друг другу :)
Windows XP, дескать, специально оптимизирована под Pentium IV, а Pentium 4 разрабатывался чуть ли не исключительно для Windows XP...
Посмотрим, что из этого получится...
Adramelek
20.03.2005, 19:31
Пару лет назад я был на одной презентации, где представители M$ и Intel взахлёб признавались в любви друг другу :)
Windows XP, дескать, специально оптимизирована под Pentium IV, а Pentium 4 разрабатывался чуть ли не исключительно для Windows XP...
Посмотрим, что из этого получится...У Microsoft'a, помнится, был уже альянс с IBM'ом... :rolleyes:
Error404
28.11.2006, 14:00
Посоветуйте, пожалуйста, хороший современный сабж для экспериментов (под Windows)!
Из того, что пробовал, пока более-менее удовлетворил DelphiSpec, но там свои проблемы...
А так -- большинство проектов недоработаны, либо кучи доп. библиотек требуют (пока скомпилишь, проклянёшь всё на свете), либо написаны настолько криво, что к коде чёрт ногу сломит...
А вот кстати: кто-нибудь пользовался этим DelphiSpec ? Чего-то там в AY8312 недоэмулировано: эмулятор постоянно хрюкает "сам с собой" даже в Idle. Никто не сталкивался? Это как-то фиксится (исходники же есть)?
[QUOTE=rg_software]"Fuse - the Free Unix Spectrum Emulator"?
Во-первых, Уних, а это значит, что для портирования под винду повозиться всё-таки придётся...
Во-вторых, при всём уважении, эти ребята юзают чистый С, что в наше время мне кажется, мягко говоря, странным... У меня нет предубеждений
[/quite]
Ну да. Современные программы должны писаться непременно на Java.
А лучше на C#. А то не заработают.
Чистый С -- язык морально устаревший. Созданный в конце семидесятых, он прекрасно отражал воззрения на программирование того времени. Сейчас в свете развития ООП и прочего, становится совершенно ясно, чего мне не хватает в С:
Мне кажется, аффтару самому ещё немного устареть, насмотреться на все ужасы ООПщины и перестать бредить -- и будет полный порядок.
1) прилично организованной модульности и средств абстракции данных (классов то бишь)
А у лыж нет колёс. Поэтому лыжи -- *****. То ли дело самокаты.
Если уж на то пошло, то зачем компромиссы? Компьютеры с сороковых существуют, а С только в 78м придумали или около того. Пиши на машинном коде. Или на фортране. В крайнем случае, на алголе, а уж С -- это слишком современно :)
Скорей, ближе к 1970.
На фортране и сейчас пишут. На современном. Алгол успешно трансформировался в несколько до сих пор востребованных языков, например в ADA. И C не совсем уж остановился в развитии. Хотя, достаточно коммерческих компиляторов, к сожалению, остановились на уровне 1989 года (в настоящее время действует "C99").
Да, C не предназначен для десктопного программирования.
Учи C#. А то придёт микрософт со своим дотнетом и вас туда не пустит (вариант: учи Java. А то придёт Sun...)
самое то. А на платформах где ресурсы - не проблема, языки очень высокого уровня (т.е. где не надо парится с индексами, указателями и алоцированием/освобождением памяти) гораздо продуктивнее. По мне для бизнес приложений Visual Basic 6, C#, PHP или Java гораздо лучше C++
На самом деле C++ позволяет почти всё, что в этих недоязыках (бейсик, хехе) есть. И многое чего нет. Но уметь этим пользоваться -- вот я не умею толком (в отличии от товарищей "знающих C++ но не знающих C").
Модульность на голом Си можно сделать через структуры, а методами таких псевдо-классов будут функции, принимающие первым аргументом указатель на структуру. STL не стоит возводить на пъедестал лекарства от всех
болезней - от кривых программистских ручек он не спасет. По поводу
STL -- никак нельзя. Мы тут, в соседнем треде, уже решили -- только C# и Java. Помогает даже от сифилиса и рака.
исключений - это припарка на больную голову программистов-чайников
Таки многие механизмы имеющиеся в C++ бывает нужны, важны и полезны. Можно конечно их пытаться эмулировать в C (хреново, попутно изобретая очередной велосипед). Только я б на первое место из ООПщины поставил не "модульность", худо-бедно реализуемую в C, и не исключения (нате вам longjmp), и даже не шаблоны (есть же мощные альтернативные макропроцессоры...), а скорей наследование.
переменную в одном модуле переменную как int, а в другом -- как extern float; этот код компилируется (!) т.к. линковка идёт по именам без проверки типов (в стандартном С)... естественно, в первом
Для этого используют *.h. И кроме того, вот hitech software орёт, мол signature don't match. Ну да, warning. Отключаемый. Так их и читать иногда полезно.
модуле все инструкции генерируются для целых, во втором -- для вещественных чисел, и программа глючит по-страшному...
Потому, как в ассемблере и компоновщике нет понятия типа данных. Он там не нужен. То же касается любого языка построенного поверх данного компоновщика...
Неужели язык должен разрешать компиляцию таких ошибочных кусков?
Неужели не должен? Всё на твоей совести.
Возможно, ты с вершины ООП даже и не в курсе, что флоатные числа на предмет больше-меньше можно СРАВНИВАТЬ целочисленными сравнениями?... слабо так на жабе сделать?
Нельзя. Ибо сравнение Nan с любым числом должно давать отрицательный разультат, чего с целочисленными сравнениями никак не получится. Если исключить нечисла -- то да, можно, наверное, никогда не задумывался зачем. Да и сравнивать на равенство так нельзя.
А че ты завелся это же год назад с геком писали, афтар небось и про форум уже забыл.
Error404
28.11.2006, 22:41
А че ты завелся это же год назад с геком писали, афтар небось и про форум уже забыл.
Это да. :smile:
Я собственно опять хочу вернуться к DelphiSpec, упомянутому в заглавном посте треда. Кто-нибудь им пользуется? Это он только у меня непрерывно подхрюкивает "муз.сопроцессором" или это у всех так?
Это да. :smile:
Я собственно опять хочу вернуться к DelphiSpec, упомянутому в заглавном посте треда. Кто-нибудь им пользуется? Это он только у меня непрерывно подхрюкивает "муз.сопроцессором" или это у всех так?
у меня тоже.. да он вообще кривой, я к нему поддержку бордюра добавлял когда-то, дак так нормальную эмуляцию и не сделал, иначе весь рендеринг пришлось бы с нуля переделывать
анрил намного приятней написан
Я собственно опять хочу вернуться к DelphiSpec, упомянутому в заглавном посте треда. Кто-нибудь им пользуется? Это он только у меня непрерывно подхрюкивает "муз.сопроцессором" или это у всех так?
Звуковая подсистема там кривовата, можно у SMT содрать принцип отдельфинить её, но в Unreal и тайминги по другому щтаются, в тоже DelphiSpec веслый прикол ставиш 200% или без ограичений скорость эмуляции то у него и флеш пропорционально увиличивается и т.д. и т.п.
у меня тоже.. да он вообще кривой, я к нему поддержку бордюра добавлял когда-то, дак так нормальную эмуляцию и не сделал, иначе весь рендеринг пришлось бы с нуля переделывать
Гы я тоже, к тому же весь рендеринг переписал
Error404
06.12.2006, 11:32
Звуковая подсистема там кривовата, можно у SMT содрать принцип отдельфинить её
[....]
Гы я тоже, к тому же весь рендеринг переписал
А как можно проверить/прошагать эмулятор AY в Spectrume? Дело в том, что на движке DelphiSpec у меня эмулируется Орион :smile: (там тоже был AY совместимо по портам с ZX и соответственно плейеры), на Орионе (и соответственно в эмуляторе) я из-под CP/M все запускать умею, а на Спектруме я дальше меню "Калькулятор/бейсик/лоадер" продвинуться не могу. :v2_blush: Чего там делать то нужно? Конечно, в однатысячадевятьсотмохнат ом году у меня было несколько Пентагонов, даже вроде несколько игр на них тогда как-то непостижимым образом запускал, но не прижились они у меня как-то (в сарае вроде до сих пор несколько догнивают). Соответственно, ничего не помню... :redface:
в басике 128 есть команды для "создания" :) звука
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot