Jump to content

    

__inline__

Участник
  • Content Count

    1012
  • Joined

Posts posted by __inline__


  1. 14 minutes ago, VladislavS said:

    Я как-то на Cortex-M4 поймал HardFault по невыровненному доступу :)

    
    template<uint32_t fifo_num>
    static inline void WriteFIFO(uint8_t *src, uint16_t len)
    {
      for (uint32_t words2write = (len+3)/4; words2write--; src += 4)
        #if defined(__ARMCC_VERSION)
          // ARMCC v6 на высокой оптимизации на *(uint32_t *)src ставит инструкцию LDM R1!,{R4}
          // которая на невыровненных данных валит в HardFault          
          *otg_dfifo<fifo_num>() = *src + (*(src+1)<<8) + (*(src+2)<<16) + (*(src+3)<<24);
        #else			 
          *otg_dfifo<fifo_num>() = *(uint32_t *)src;
        #endif
    }

     

     

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

    А ещё меня дураком пытаются выставить такие как jcxz ! :lol2:

    Просто завидуют:  ведь Allwinner уделал C6745 до слёз , а для jcxz этот DSP - это "священная корова" :laugh2: Вот и хейтит он мои посты теперь, прикапываясь по мелочам. 

    hacker_fox тоже уже на подходе, почти...

  2. 1 hour ago, haker_fox said:

    Вы вводите в заблуждение своих коллег.

     

    В каком месте?

     

    1 hour ago, haker_fox said:

    А в этой теме кто-то стебётся, хотя и знает правильный ответ. Или просто даёт левые советы.

     

    Кто этот кто-то и какие левые советы он дал в этой теме?

     

    1 hour ago, haker_fox said:

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

     

    В каком месте и кого именно я ввёл в заблуждение?

    Каких коллег вы имеете в виду? Перечислите.

     

  3. 14 minutes ago, jcxz said:

    Так значит всё это был пустой трёп?

    Такой же как и трёп и наезды на "неработающий" аллокатор который типа "гумно"? Которые в результате оказались результатом багов в вашем собственном быдлокоде.

    Или другие подобные же вопли про "г*вно" и "отстой". Которые очень часто звучат в ваших темах...

     

    PS: У меня в последнее время большие сомнения в вашей адекватности.....

     

    Вы наверное будете удивлены, что мне совершенно безразлично что вы там считаете о моей адекватности или её отсутствии. Слишком всё уныло обобщаете. Я даже не буду тратить своё время на дальнейшее разжёвывание. :dance:

     

    В данном случае я просто стебусь и не более. В таком состоянии бесполезно меня взывать к ответам. Тем более данный форум -  ничем не обязывает.  Так что смиритесь с тем, что мои посты будут у вас вызывать раздражение.  Более того, вы можете внести в ЧС мой ник и более сообщений от меня не увидите.  Но вот так воспаляться по каждому моему посту - это уже похоже на ничем непрекрытое хейтерство )))) :lol2:

     

    Найдите себе другого субъекта для битья. А ещё лучше - поберегите свои нервы и время! :bb:

     

     

  4. 36 minutes ago, jcxz said:

    Вопрос был про Cortex-M7

     

    Ага, по вашему STM32H743 это не Cortex-M7 ? :biggrin::lol2:  Тут вы и попались! :laugh3:

     

    36 minutes ago, jcxz said:

    Пожалуйста - приведите конкретный пример.

     

    Не хочу... :tease:

  5. 22 hours ago, jcxz said:

    К чему? Просветите.

     

    У меня на BlackFin и STM32 были исключения из-за невыровненной памяти.  А вот в C6745 просто читался мусор, пока не заиспольовал _mem(), _mem8().  Тоесть компилятор почему-то подставляет инструкции, не учитывающие доступ по невыровненным адресам.

     

    Пользуясь случаем, глянул в сорцы эмуля СЕГи, который когда-то адаптировал под C6745 и увидел, что использование инструкций через интринсики, дало увеличение производительности чуть-ли не в 2 раза в рендерере эмулятора: вместо 4-х побайтовых  обращений используется - ОДНА инструкция с невыровненным доступом, что очень сильно увеличивает скорость:

     

    #define ALIGN_LONG 0 /* !!! unaligned word */
    
    #if ALIGN_LONG
    
    /* Or change the names if you depend on these from elsewhere.. */
    #undef WRITE_LONG
    
    static __inline__ void WRITE_LONG(void *address, uint32 data)
    {
                *((uint8 *)address++) = data;
                *((uint8 *)address++) = data>> 8;
                *((uint8 *)address++) = data>>16;
                *((uint8 *)address  ) = data>>24;
                return;
    }
    
    #endif
    
    #if ALIGN_LONG
    
    /* Draw a single 8-pixel column */
    #define DRAW_COLUMN(ATTR, LINE) \
        atex = atex_table[(ATTR >> 13) & 7]; \
        src = (uint32 *)&bg_pattern_cache[(ATTR & 0x1FFF) << 6 | (LINE)]; \
        WRITE_LONG(dst++, *src++ | atex); \
        WRITE_LONG(dst++, *src++ | atex); \
        ATTR >>= 16;  \
        atex = atex_table[(ATTR >> 13)/* & 7*/]; \
        src = (uint32 *)&bg_pattern_cache[(ATTR & 0x1FFF) << 6 | (LINE)]; \
        WRITE_LONG(dst++, *src++ | atex); \
        WRITE_LONG(dst++, *src++ | atex); \
    
    #else
    
    #define DRAW_COLUMN(ATTR, LINE) \
        atex = atex_table[(ATTR >> 13) & 7]; \
        src = (uint32*)&bg_pattern_cache[(ATTR & 0x1FFF) << 6 | (LINE)]; \
        _mem4(dst++) = (_mem4(src++) | atex); \
        _mem4(dst++) = (_mem4(src++) | atex); \
        ATTR >>= 16; \
        atex = atex_table[(ATTR >> 13) & 7]; \
        src = (uint32*)&bg_pattern_cache[(ATTR & 0x1FFF) << 6 | (LINE)]; \
        _mem4(dst++) = (_mem4(src++) | atex); \
        _mem4(dst++) = (_mem4(src++) | atex); \
    
    #endif
    
    #if ALIGN_LONG
    
    /* Draw a single 16-pixel column */
    #define DRAW_COLUMN_IM2(ATTR, LINE) \
        atex = atex_table[(ATTR >> 13) & 7]; \
        offs = (ATTR & 0x03FF) << 7 | (ATTR & 0x1800) << 6 | (LINE); \
        if(ATTR & 0x1000) offs ^= 0x40; \
        src = (uint32 *)&bg_pattern_cache[offs]; \
        WRITE_LONG(dst++, *src++ | atex); \
        WRITE_LONG(dst++, *src++ | atex); \
        ATTR >>= 16; \
        atex = atex_table[(ATTR >> 13)/* & 7*/]; \
        offs = (ATTR & 0x03FF) << 7 | (ATTR & 0x1800) << 6 | (LINE); \
        if(ATTR & 0x1000) offs ^= 0x40; \
        src = (uint32 *)&bg_pattern_cache[offs]; \
        WRITE_LONG(dst++, *src++ | atex); \
        WRITE_LONG(dst++, *src++ | atex); \
    
    #else
    
    #define DRAW_COLUMN_IM2(ATTR, LINE) \
        atex = atex_table[(ATTR >> 13) & 7]; \
        offs = (ATTR & 0x03FF) << 7 | (ATTR & 0x1800) << 6 | (LINE); \
        if(ATTR & 0x1000) offs ^= 0x40; \
        src = (uint32*)&bg_pattern_cache[offs]; \
        _mem4(dst++) = (_mem4(src++) | atex); \
        _mem4(dst++) = (_mem4(src++) | atex); \
        ATTR >>= 16; \
        atex = atex_table[(ATTR >> 13) & 7]; \
        offs = (ATTR & 0x03FF) << 7 | (ATTR & 0x1800) << 6 | (LINE); \
        if(ATTR & 0x1000) offs ^= 0x40; \
        src = (uint32*)&bg_pattern_cache[offs]; \
        _mem4(dst++) = (_mem4(src++) | atex); \
        _mem4(dst++) = (_mem4(src++) | atex); \
    
    #endif

     

    Если же выравнивание никак не учитывать (не применять _mem*() или не делать побайтовое чтение)  , то эмулятор просто повисает и вылетает в data misaligned Exception :)

     

     

    22 hours ago, haker_fox said:

    Начиная с Cortex-M3, это всё успешно будет считано с памяти. Чуть медленне, чем выровненные, но считано)

    Cortex-M0 всегда вывилится в HardFault.

     

    Класс! :good3: Вполне исчерпывающий ответ!

  6. 12 minutes ago, jcxz said:

    И какой именно компилятор использует для работы с обычными переменными short и long на Cortex-M инструкции, требующие выравнивания - можете назвать о каком именно компиляторе речь?

    "Обычные переменные" - это значит не требующие например эксклюзивного доступа.

     

    Компилятор здесь не причём.  Я говорил о случае, когда идёт  чтение short по адресу не кратному 2 или long по адресу не кратному 4.

     Хотя бы вот такой пример:

     

    short a=*(short*)(0xC0000001);
    int b=*(int*)(0xC0000007);

       

    Надеюсь, не надо пояснять, к чему приведут такие обращения к памяти? :clapping:

    Мы не знаем как автор топика обращается к данным, а это значит, что имею право предположить что выше :biggrin:

     

    Quote

    MPU_InitStruct.BaseAddress = 0xC0000000;

     

  7. 20 hours ago, Realking said:

    складывается ощущение, что перестает работать refresh (при тестировании памяти - ошибка данных)

     

    __Мои__ предположения:

     

    1) Нет контакта со стробом чтения или других контактов (проверить качество контактов MPU, DRAM и на предмет К.З.)

    2) Неисправная память или не подходит по времянкам

     

    Quote

    Есть плата с STM32h743 и SDRAM IS42S83200J.

     

    3) Ошибка в соединении DRAM и MPU.  Плата своя или фирменная?

     

     

    20 hours ago, Realking said:

    С отключенным кэшированием все гуд, но тогда вылетает unaligned fault.

     

    4) Что-то не так с выравниванием данных в программе (short д.б. выравнены на 2 байта, long - на 4, long long - на 8).

     

    Без текста программы тестилки - гадание на кофейной гуще.

  8. 14 hours ago, Spym said:

    Да, спасибо. Это снимает необоснованные подозрения с аллокатора. Не могли бы вы отредактировать упомянутый ваш пост?

     

    Уже поздно, кнопка Edit Post отсутствует.

    К тому же вы также внесли свою лепту и размножили этот пост:

     

      

    Да и чего вы так боитесь? Умный всё поймёт правильно. А дурак не осилит.

     

    Тем более вы писали:

    Quote

    Пожалуйста, либо внесите ясность, либо отредактируйте пост.

      

    Ваша просьба удовлетворена.

     

  9. 14 minutes ago, Spym said:

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

     

    А меня задевает, что у вас позиция: "Я - Д'Артаньян, а остальные пи****сы", иначе как понять ваше высказывание про:

     

    15 minutes ago, Spym said:

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

     

    Скажу так, что мне необязательно разбираться в кишках аллокатора, более того, я туда не лез. Так что вы лжёте по поводу:

     

    16 minutes ago, Spym said:

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

       

    Интересно, кто вы собственно такой, чтобы давать такие заключения другим людям? 

     

    19 minutes ago, Spym said:

    В своём первом посте об этой библиотеке (пятый пост в этой теме) вы говорили о замедлении, сбое, и зависании. Меня интересуют именно вот эти явления. Аллокатор постоянной вычислительной сложности в принципе не может приводить к замедлению и зависанию сам по себе; если вы посмотрите исходники, вы не увидите там ни одного цикла (кроме как при вычислении двоичного логарифма, если быть максимально педантичным). Можете ли вы подтвердить, что вы действительно наблюдали описанные эффекты?

     

    Вам легче станет, если скажу, что "замедление-сбой-подвисание" -  это следствие того, что malloc вернул NULL, и программа пошла шагать дальше, а не застопорилась, как сделано в последнем случае?

     

    20 minutes ago, Spym said:

    Я склоняюсь к версии, что тест был выполнен не вполне добросовестно, и ваш первый отзыв вводит людей в заблуждение. Пожалуйста, либо внесите ясность, либо отредактируйте пост.

     

    Вы имеете право думать о чём угодно.  Я имею право писать о чём угодно.  В интернете, вам никто  ничем не обязан.

    А раз выкладываете свой код  для пользования другими, будьте готовы увидеть любые отзывы, в том числе невыгодные вам !

    Ваш диалог уже получается НЛП какое-то: насквозь прошпигован угрозами и призывом к ответственности.  Далеко пойдёте... :biggrin:

       

    Напоследок скажу, ваш аллокатор неоптимально использует пул памяти, по сравнению с другими.  Надеюсь, я оставил вас довольным своим ответом!

    И скажите спасибо, что вашему аллокатору выделил своё время ДВАЖДЫ! :lazy:

  10. 16 minutes ago, mantech said:

    Так и делаю, иначе при требовании под 1 кадр 2-4 мегабайта, никакой памяти не хватит. Распаковку провожу в то время, пока клиент что-то делает не касаясь терминала.

     

    Декодер H264 напрашивается. Там хорошее сжатие между фреймами и опенсорцный.  Можно настроить качество не хуже JPEG.

     

     

    Странные клиенты. Чем ведро многоядерное по типу планшета их не устроило?

  11. 5 hours ago, Spym said:

    Тогда, пожалуйста, поделитесь сведениями о характере обнаруженного сбоя

     

    Убедили!  Всё-же ещё раз выделил квант своего времени и ещё раз всё проверил, сделал контрольную проверку возвращаемого значения после malloc.

     

    5 hours ago, Spym said:

    подтвердите, что ваша программа исполняется в одном потоке.

     

    На голом железе. Там один поток.  Есть прерывание для подкачки данных для звука, но там статическое распределение - буфер постоянной длины: обычный массив.

     

    5 hours ago, Spym said:

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

       

    Проверка показала, что malloc вернул NULL спустя какое-то время, дисплей покрасился в красный цвет, и далее я сделал вечное зацикливание.   Недостаточно памяти.  Данный аллокатор либо неэффективно (по сравнению с другими)  использует кучу, либо куча сильно фрагментировалась.

     

    Пул 24 Мегабайта.  Адрес пула 0xC2000000 - выравнивание - овердофига, чем надо.   Штатный и zltig'овский аллокаторы с этим пулом работают, ошибок выделения памяти нет.  Условия теже самые.

     

    Ниже обёртка, на которой тестировались все сторонние аллокаторы:

     

    /*
    o1.cpp
    cpp-wrapper for o1heap
    */
    
    #include <string.h>
    //#include <stdio.h>
    #include <stddef.h>
    
    #include "o1heap.h"
    
    #include "API.h" //это API для работы с дисплеем, звуком, и т.п.
    
    static O1HeapInstance *o1i;
    
    #define HEAP_MEMORY_SIZE (24UL*0x100000UL) /* 24 МБ */
    
    //static char HEAP_MEMORY[HEAP_MEMORY_SIZE] __attribute__ ((aligned (64))); //это для винды
      
    static char *HEAP_MEMORY=(char*)0xC2000000; //с этого адреса лежит пул кучи (свободный участок, неиспользуемый более никем)
    
    extern "C" void *malloc(size_t size)
    {
     static char f=1;
     if(f)
     {
      o1i=o1heapInit((void*)HEAP_MEMORY,HEAP_MEMORY_SIZE,NULL,NULL); //одноразово инитим аллокатор
      f=0;
     }
    
     void *r;
     if(!size)
     {
    //  printf("malloc size=0\n");
      return NULL;
     }
     r=o1heapAllocate(o1i,size);
    
    // if(r)printf("malloc=%d\n",size);
    // else printf("malloc error: not enougth memory\n");
    
     if(r==NULL) //если выделить не удалось
     {
      ClearVRAM(COLOR_RED); //заливаем буфер видео красным цветом
      OutLCD();             //выводим буфер на дисплей
      while(1);             //зацикливаем навечно
     }
    
     return r;
    }
    
    extern "C" void free(void *ptr)
    {
    // printf("free\n\n");
    
     if(ptr==NULL)return;
    
     o1heapFree(o1i,ptr);
    }
    
    extern "C" void *calloc(size_t num,size_t size)
    {
    // printf(" CALLOC ");
     size_t ns=num*size;
     void *r=malloc(ns);
     if(r)memset(r,0,ns);
     return r;
    }
    
    extern "C" void *realloc(void *ptr,size_t newsize)
    {
    // printf(" REALLOC ");
    
     if(ptr==NULL)return malloc(newsize); //только выделяем
    
     if(newsize==0) //только освобождаем
     {
      free(ptr);
      return NULL;
     }
    
     void *new_ptr=malloc(newsize);
     memcpy(new_ptr,ptr,newsize); //копируем старый фрагмент в новый
     free(ptr);
    
     return new_ptr;
    }
    
    void *operator new(size_t sz)
    {
    // printf(" NEW 1 ");
     return malloc(sz);
    }
    
    void *operator new[](size_t sz)
    {
    // printf(" NEW 2 ");
     return malloc(sz);
    }
    
    void operator delete(void *ptr)
    {
    // printf(" DELETE 1 ");
     free(ptr);
    }
    
    void operator delete[](void *ptr)
    {
    // printf(" DELETE 2 ");
     free(ptr);
    }

     

  12. 54 minutes ago, mantech said:

    Никогда этим не пользовался, но неужели этого еще нет в сях??

     

    В ARMCC это делается через эмбид ресурсов через ASM-файлы.

    В GCC это делается через objdump + внешние extern

    В других, где эмбида нет - только конверсией BIN to H.

     

    56 minutes ago, mantech said:

    Будет слайд-шоу, особенно на анимации

     

    А если разом всю анимацию из памяти(1) разжать в память(2), затем играть из памяти(2)?   Затем освободить память(2),  а из памяти (1) новую анимацию в память(2) ит.п.?

     

  13. 20 minutes ago, Spym said:

    Я готов найти ошибку в вашем бенчмарке, если вы его здесь выложите.

       

    Бенчмарки не использую (оставим их учёным и академикам для лабораторных исследований сферических коней в вакууме и для маркетологических статистик не имеющих ничего общего с реальностью),  а выкладывать целиком весь код целевой программы  нет ни желания, ни прав.

     

    Проблема вылезала не сразу, а по прошествию какого-то времени.  Полагаю, алгоритм того аллокатора что-то не учёл. Иными словами, он не резистентен к случаям, которые предусмотрены в штатных аллокаторах (C6000+ и GNU ARM) и в аллокаторе, от zltigo.

      

    Я сомневаюсь в вашем авторстве того кода.  Скорее всего вам стало скучно и прикалываетесь.

     

  14. 14 minutes ago, Spym said:

    1. есть требования по выравниванию буфера (как в большинстве аллокаторов)

     

    С этим как раз всё ОК.  Программе нужно выравнивание, намного бОльшее, чем требует аллокатор.

     

    14 minutes ago, Spym said:

    2. функция инциализации вернёт NULL, если буфер не выровнен (вы этого не проверили);

     

    Если я об этом не пишу, то это не значит, что этого не сделано. В данном случае этот момент не представлен общественности, так как посчитал эту элементарщину неуместной публикации.

    Любой сторонний аллокатор проверяется вначале подобными проверками.

     

    14 minutes ago, Spym said:

    3. фраза "а фиг его знает" указывает на то, что вы не посмотрели даже README.

     

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

     

    14 minutes ago, Spym said:

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

     

    Эти "третьесортные бенчмарки", как вы выразились, со штатным аллокатором ведут игру ОТ и ДО без эксепшенов. Аллокатор zltigo  также  работает успешно ОТ и ДО (не считая выкрутасов mingw вначале).

     

     А этот аллокатор завалил работу программы через  пару секунд,  при этом несколько аллокаций-освобождений всё-же успешно произошли.   Значит что-то пошло не так!

      

    14 minutes ago, Spym said:

    Библиотека моя.

     

    Сомневаюсь!

    Просто решили потроллить.

     

    Проблема решена, читайте выше, даже штатный аллокатор вернули! :sun_bespectacled:

     

    P.S.   https://electronix.ru/forum/index.php?app=core&module=members&controller=profile&id=35348

     

    Дата последнего поста:  October 15, 2014

     

    Прошло 7 лет с тех пор...

     

    Странно это всё.  В последнее время часто вижу на форуме выходящих из долгой спячки  персонажей.   Тенденция? :acute:

     

     

  15. On 9/16/2020 at 8:53 PM, Aldec said:

    Отсутствие защиты от перезаписи или  отдельного кэша  для пары  регистров приводит к бэкдору.   

     

    Самый большой бэкдор - в башке человека. :biggrin:

     

    On 9/16/2020 at 8:53 PM, Aldec said:

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

     

    С таким подходом вам нужно содержать собственную силиконовую фабрику и разрабатывать свои кристаллы со своей архитектурой.  И не забыть тщательно  проверять кадров при приёме на работу. :big_boss:

     

    Если по существу, то давление есть - 100%!

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

    Естественно, исходный текст этих функций никто не видел, дают как extern.

     

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

     

    Туда же online-апдейт фирмвари ST Link для контроллеров STM :bye:

  16. 9 hours ago, mantech said:

    Нее, так не хотят, хотят, чтоб нажав на кнопку сразу появилась картинка, причем на весь экран! Я как-то делал динам. подзагрузку, когда дело было на более простом МК - сразу фи.. а чет так думает, хочу сразу чтобы)))

     

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

     

    Тоесть в образе прошивки скомпонованы ресурсы сжатые ZLIB (на ПК предварительно с самым сильным сжатием -9 ), а при обращении к ним делается прозрачная распаковка(из памяти конечно).

     

    В играх так и сделали: заменили fopen, fread, fclose на свои - которые читают из памяти якобы файлы (на самом деле - сжатые образы в памяти).  Правда тогда нужно будет организовать некий хедер (наподобие как таблица FAT) из которого как минимум будут извлекаться: имя ресурса, его размер и смещение относительно базового адреса ресурса.  Что-то типа  своего Data-Bundle.   Так кстати в играх укатывают все ресурсы данных в один файл, который можно пристыковать к программе (GCC это может "изкаропки", для остальных - через конверсию bin to h) .

     

    А если взять smart-RLE-сжатие, то можно прямо побайтно налету разжимать картинки ))) Но по степени сжатия RLE хуже ZLIB.

     

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

     

    Кстати, грядёт новый стандарт Си, надеюсь разработчики компилеров не прозевают и сделают все __полезные__ нововведения: https://habr.com/ru/company/badoo/blog/503140/

     

    Особенно вот это наконец-то будет кросс-платформенно:

     

    Quote

    Включение двоичных файлов в исходный файл

    Включение двоичных данных из файлов в исполняемый файл — невероятно полезная для всех игроделов возможность :

     

    const int music[] = {
       #embed int "music.wav"
    };

     

     

     

    10 hours ago, Obam said:

    Чёт он на Сильвестра не похож: овал лица не тот, "баландын", без сигареты в углу рта и без зеркальных "Авиатор"-ов ;-). Фальшивка.

     

    Мне здесь больше дерзкая китайская выходка против игровых копирасторов понравилась :biggrin:

     

    И решь шла не о Кобре-Сталлоне, а о японском Кобре.

     

    Вот этот товарищ:

     

    360

     

    И этот :

     

    x1000

     

    - разные люди, не пересекающиеся друг с другом. :lol2:

     

  17. On 9/10/2020 at 7:18 AM, GenaSPB said:

    Офтоп... я у нас в питере вижу этого неунывающего персонажа на футболках... Правда без сигары... Наверное, чтобы не пропогандировал.

     

    Случайно на али-экспресс увидел такую майку с Коброй :

     

    Classic-Manga-Space-Adventure-Cobra-T-Shirt-Men-Short-Sleeve-80s-Japanese-Anime-T-shirt-Cotton.jpg_q50.thumb.png.ce400f291771db5dfddd057209c715dc.png

     

    Была Контра - стал Кобра :lol2::lol2::lol2:  Времена меняются...

     

     

     

    1 hour ago, mantech said:

    Ну вы даете)))  Я даже в бареметал еле-еле смогу свой проект уложить в 64мега (не программу, она меньше мегабайта, а хранилище скриптов, шрифтов, видеофреймбуфера верхнего и нижнего слоев, форм, 32х битных картинок с разрешением 1366х768, а еще и анимацию хотят теперь клиенты)...

       

    Так, а со сжатием как дела обстоят?

      

    Мы когда делаем игры, поступаем так: сжимаем всё что сжимается ZLIB и кладём на SD карту.  Затем когда что-то нужно подгрузить для конкретного уровня игры - лезем в динамический список - грузим и разжимаем в память то что нужно.  Уровень заканчивается - освобождаем ресурс памяти.  Далее из нового списка грузим в память и разжимаем объекты для нового уровня. И т.д.

       

    Ресурсы игры разношерстные:  звуки, музыка, спрайтовые атласы, карта уровня, динамические списки, таблицы атрибутов.  За всё про всё пока хватало кучи на 24 МБ на разжатые данные.  Хотя общий объём сжатых данных на SD-карте - около 40 МБ.

     

    Cам код игры сейчас около 700 кБ для ARM и  чуть более 1 МБ для C6745 (у обоих - жёсткая оптимизация по скорости, размер кода при этом  неоптимален)

  18. Из всего вышеперечисленного мне интересен только бОльший размер памяти.

    Хотя держусь пока в пределах 32 МБ :wink: (приложениям хватает.  Больше всего - расходы на HEAP.  Затем STACK, а потом лишь BSS, ZI. И в последнюю очередь RO/text )

  19. Часто так выходит, что решаешь проблему X, а на самом деле причина скрыта в проблеме Y.  Так и в этом случае: думал что аллокатор памяти тормозит, а оказалось было слабое место в игре.

     

    Более подробнее здесь: https://gamedev.ru/code/forum/?id=255201

     

    И здесь:

     

    Всем спасибо, кто откликнулся!:ok:

     

     

    Проблемное место, где было замедление:

     

    file.gif

     

     

    Результат:

     

     Результат заснят здесь (с 40-й секунды):

     

    https://www.youtube.com/watch?v=lCq6wd2YA10&t=40

     

     

  20. 3 hours ago, mantech said:

    В моем понимании было б удобно модуль, с мин. обвязкой, с процом S3 и краевыми контактами, размером не более 3х3см. Занялся бы сам этим, но трудозатраты по разработке не маленькие, плюс поиск адекватного подрядчика на пайку - отнимает много времени. Да и китайцы продают данные процы по 2000 шт и более, если меньше - далеко не каждый готов и ценник раза в 2 больше.

     

    Если сравнить V3s и S3, то по каким показателям S3 вам кажется привлекательнее?