Ну если разрушаемый, то да. Но я видел в Master of Orion 3 , там до 300мб сохранения. Хотя там 100 планет. Там максимум жителей 20, для каждого специализация - это байт. Ну ещё зданий 20, тип здания это ещё байт. Ну и всего параметров 100 максимум. Это 10 Кб. Ещё 10 Кб на флоты всех фракций.
В Total war Shogun где-то 15 Мб сохранение. В Thrones of Britania наняли уже студент и стало 7Мб , хотя информация для сохранения примерно такая же.
В шутере Quake 4 тоже 7Мб сохранение, я не помню, чтобы там особо был разрушаемые уровни.
Вот примерно такая же тема. Я всё удивляюсь ,какие школьники пишут сохранения для игр , что они по 100 Мб занимают. При том что там максимум 1000-2000 параметров. Как-то сам опенсорсную игру писал. Там халтурное всё , и AI и графика и конечно же система сохранения. Но больше чем на 100 Кб всё равно они не занимали даже после нескольких часов игры(а по хорошему можно и в 10 Кб уместить). В общем как пишут сохранялки , чтобы они 100 Мб занимали, для меня так и осталось загадкой. Может быть просто дамп памяти сгружают в файл? Или надо ещё какой-то дзен познать, чтобы такие делать?
Спасибо , может мне пригодится. Интересно, как он внутри работает. В коде ByteBuffer.java описываются getFloat() и putFloat(float f) но самого кода , как это работает нет.
Единственное ,нашёл в модуле bits что-то вроде такого
У нас на порт приходит пакет 10 байтов. На самом деле же это числа по 2 или 4 байта + заголовок и контрольная сумма.
Есть конечно дуболомный вариант. Что если не самый старший байт <0 , то добавляем 256. И потом ещё умножаем на 256 в зависимости от того какой разряд. Но по мне , подход так себе.
----
Про два байта вы правы, такой код не универсальный, для универсальности надо делать костыли.
И как в том же Java так же сделать? Возможно какие-то нормальные обходные пути и есть. Но я в Java максимум быдлокодер, таких не знаю, поэтому приходилось делать громоздкую конструкцию, где я при замене 32 битного значения вручную менял и массив и наоборот. А тут всё быстро и автоматически.
Естественно с первого раза конструкция не взлетела пришлось потом тратить время на вылавливание ошибок.
Ну так это регресс будет , если народ будет преждевременно на пенсию отправлятся, когда бы мог ещё поработать. В итоге на место ушедшего надо кого-то нового брать, а этот новый и молодой ещё бы где пригодился. Вот пример, есть пенсионеры, которые на КОБОЛЕ программируют. Если все системы на КОБОЛ заменить на новые будет прогресс? По мне так будет регресс, т.к. многие программисты вместо того, чтобы действительно нужные задачи решать, будут просто переписывать системы , которые уже работают на другой язык, лепить новые баги и т.д.
"Каждый раз, когда я ищу новое расположение пункта меню или обновившуюся иконку, у меня сбивается рабочий ритм. " - раньше я удивлялся, почему некоторые так любят консольные команды. Ведь меню же быстрее и эффективнее.
Однако в каждой новой версии программы "умные люди" постоянно меняют меню. А консольные команды-то такие же десятилетиями.
Ну это не совсем настоящая крипта. Так же как Ripple не настоящая потому, что на самом деле централизованная. Так что да , надо различать крипту и лжекрипту, а то можно сильно пролететь. Впрочем с настоящей тоже можно пролететь. :-)
Тюльпаны можно вырастить в какой-то момент столько, чтобы обвалить рынок. Крипту труднее напечатать, хотя инфляция всё же есть в виде появления новых криптовалют.
Ну типичные циклы биткоина. В прошлый раз он с пика 20 000 упал ниже 5000 и потом 3 года на дне валялся. Кефириум и так и вообще с 1300 стал в какой-то момент меньше 100$ .
Автор кстати провидец - предсказал, что "настоящие программисты" в будущем пересядут на Си :-)
Ну и также Pascal он явно недооценил, т.к. многие программы на нём вылетают с Access violation , а многопоточные программы вообще требуют особой квалификации настоящего программиста.
Смотря какое. Многие образцы старого кода считают быдлокодерством т.к. не в когда нет классов, много глобальных переменных, даже функции и то вызываются редко и большие.
Но зато по скорости это работает намного быстрее сегодняшнего условно хорошего кода.
Ну далеко не сразу, а если джуном где-то поработали. В экзотических случаях, если свой проект создали. Ну и плюс те, кто на мидла устраиваются не все мидлы :-)
Переиспользование кода эта боль. Я в своё время нагородил целый транслятор кода с Дельфи на си, который транслировал по разному на разные контроллеры PIC. Ну ясно он поглючивал, как любая такая поделка. Но зато позволял кое-что протестировать в среде Дельфи и даже писать с классами.
Статью тяжело понять, но если верно ухватил мысль автора, то она противоречит второму закону термодинамики по которому энергия не идёт "отовсюду" в одну точку, а наоборот, постепенно распыляется "повсюду".
Ну если разрушаемый, то да. Но я видел в Master of Orion 3 , там до 300мб сохранения. Хотя там 100 планет. Там максимум жителей 20, для каждого специализация - это байт. Ну ещё зданий 20, тип здания это ещё байт. Ну и всего параметров 100 максимум. Это 10 Кб. Ещё 10 Кб на флоты всех фракций.
В Total war Shogun где-то 15 Мб сохранение. В Thrones of Britania наняли уже студент и стало 7Мб , хотя информация для сохранения примерно такая же.
В шутере Quake 4 тоже 7Мб сохранение, я не помню, чтобы там особо был разрушаемые уровни.
Вот примерно такая же тема. Я всё удивляюсь ,какие школьники пишут сохранения для игр , что они по 100 Мб занимают. При том что там максимум 1000-2000 параметров. Как-то сам опенсорсную игру писал. Там халтурное всё , и AI и графика и конечно же система сохранения. Но больше чем на 100 Кб всё равно они не занимали даже после нескольких часов игры(а по хорошему можно и в 10 Кб уместить). В общем как пишут сохранялки , чтобы они 100 Мб занимали, для меня так и осталось загадкой. Может быть просто дамп памяти сгружают в файл? Или надо ещё какой-то дзен познать, чтобы такие делать?
Спасибо , может мне пригодится. Интересно, как он внутри работает. В коде ByteBuffer.java описываются getFloat() и putFloat(float f) но самого кода , как это работает нет.
Единственное ,нашёл в модуле bits что-то вроде такого
static private int makeInt(byte b3, byte b2, byte b1, byte b0) { return (((b3 ) << 24) | ((b2 & 0xff) << 16) | ((b1 & 0xff) << 8) | ((b0 & 0xff) ));}
И как это сделать в Java без помощи юнион?
У нас на порт приходит пакет 10 байтов. На самом деле же это числа по 2 или 4 байта + заголовок и контрольная сумма.
Есть конечно дуболомный вариант. Что если не самый старший байт <0 , то добавляем 256. И потом ещё умножаем на 256 в зависимости от того какой разряд. Но по мне , подход так себе.
----
Про два байта вы правы, такой код не универсальный, для универсальности надо делать костыли.
С помощью union можно сделать например так
typedef struct {union{unsigned int address;unsigned char bytes[4];}} ipv4_address;И как в том же Java так же сделать? Возможно какие-то нормальные обходные пути и есть. Но я в Java максимум быдлокодер, таких не знаю, поэтому приходилось делать громоздкую конструкцию, где я при замене 32 битного значения вручную менял и массив и наоборот. А тут всё быстро и автоматически.
Естественно с первого раза конструкция не взлетела пришлось потом тратить время на вылавливание ошибок.
Ну так это регресс будет , если народ будет преждевременно на пенсию отправлятся, когда бы мог ещё поработать. В итоге на место ушедшего надо кого-то нового брать, а этот новый и молодой ещё бы где пригодился. Вот пример, есть пенсионеры, которые на КОБОЛЕ программируют. Если все системы на КОБОЛ заменить на новые будет прогресс? По мне так будет регресс, т.к. многие программисты вместо того, чтобы действительно нужные задачи решать, будут просто переписывать системы , которые уже работают на другой язык, лепить новые баги и т.д.
"Каждый раз, когда я ищу новое расположение пункта меню или обновившуюся иконку, у меня сбивается рабочий ритм. " - раньше я удивлялся, почему некоторые так любят консольные команды. Ведь меню же быстрее и эффективнее.
Однако в каждой новой версии программы "умные люди" постоянно меняют меню. А консольные команды-то такие же десятилетиями.
Ну это не совсем настоящая крипта. Так же как Ripple не настоящая потому, что на самом деле централизованная. Так что да , надо различать крипту и лжекрипту, а то можно сильно пролететь. Впрочем с настоящей тоже можно пролететь. :-)
Слабые нынче шайтаны пошли. Раньше вот они могли принять облик человека. А также удалённо общаться даже и без интернета!
Помню на патриотических ресурсах говорили - ну и что , что в разы дороже. Зато ведь своё.
Тюльпаны можно вырастить в какой-то момент столько, чтобы обвалить рынок. Крипту труднее напечатать, хотя инфляция всё же есть в виде появления новых криптовалют.
Ну типичные циклы биткоина. В прошлый раз он с пика 20 000 упал ниже 5000 и потом 3 года на дне валялся. Кефириум и так и вообще с 1300 стал в какой-то момент меньше 100$ .
В своё время вот пытались делать сайты на IntraWeb -там тоже всё делает бинарник. Не взлетело.
Автор кстати провидец - предсказал, что "настоящие программисты" в будущем пересядут на Си :-)
Ну и также Pascal он явно недооценил, т.к. многие программы на нём вылетают с Access violation , а многопоточные программы вообще требуют особой квалификации настоящего программиста.
Смотря какое. Многие образцы старого кода считают быдлокодерством т.к. не в когда нет классов, много глобальных переменных, даже функции и то вызываются редко и большие.
Но зато по скорости это работает намного быстрее сегодняшнего условно хорошего кода.
Кстати говоря в некоторых проектах именно так и надо. Сначала программирует Серёжа. Когда поддержка слишком сложна производиться глубокий рефакторинг.
А когда делают "сразу хорошо" часто оказывается не то, не туда масштабируется , рефакторинг сделать ещё сложнее, чем для кода Серёжи.
Так можно три года в джунах поработать, и будешь миддлом. При этом ещё за это джуну будут платить , а не наоборот :-)
Ну далеко не сразу, а если джуном где-то поработали. В экзотических случаях, если свой проект создали. Ну и плюс те, кто на мидла устраиваются не все мидлы :-)
Переиспользование кода эта боль. Я в своё время нагородил целый транслятор кода с Дельфи на си, который транслировал по разному на разные контроллеры PIC. Ну ясно он поглючивал, как любая такая поделка. Но зато позволял кое-что протестировать в среде Дельфи и даже писать с классами.
Статью тяжело понять, но если верно ухватил мысль автора, то она противоречит второму закону термодинамики по которому энергия не идёт "отовсюду" в одну точку, а наоборот, постепенно распыляется "повсюду".