Compression Oriented Programming

[stoiko]

ето това е начина по който и аз се опитвам да пиша код и според мен всички неопитни (и не само) програмисти трябва да си го набият в главата:
http://mollyrocket.com/casey/stream_0019.html

[pdimov]

Добра е статията.

[KosSiO]

Ами на мен лично не ми харесва. Може би формулата е добра(но хайде кой не се опитва да иснася сичко на функции), може би описанието не му се е получило добре.

Хареса ми отделянето на под-стъпките от функция в блокове, аз също го правя (не и на работа за съжаление) и доста опростява четенето на кода.

Като цяло не знам дали тва беше част от примера, но именоването на променливи/фунции адски много му куца.
float title_height = draw_title(at_x, at_y, title); <------- това е ужасяващо draw_title кой очаква тва да връща няква височина каква е тая височина, на кого от къде?
layout.row(); layout.complete(this) и други

Останалото е ясно че всички го правят по-един или друг начин. Всеки събира логигата на едно(но има едни хора дето я събират по макрота...).
Но признавам че при мен хода е грешен(спрямо него) в който се случват нещата (винаги 1во описвам някаква минималистична струтурка(ако вече няма))

Моя стил на писане пък се върти около const.

[stoiko]

float title_height = draw_title(at_x, at_y, title); <------- това е ужасяващо draw_title кой очаква тва да връща няква височина каква е тая височина, на кого от къде?

какво точно не разбираш от тоя ред специално? това е IMGUI и тези размери може да се генерират/подават насам-натам всеки кадър.

[gemicha]

Чета в началото и ми звучи много познато. Започва с грешно използване на инструмент до ниво на пълно обезсмисляне. После се прави заключение, че инструмента е лош. Нито за момент не са допуска, че може да е използван погрешно. Вместо да прочете и научи как да го ползва правилно решава, че знае как. Та той е написал хиляди редове с код и е публикувал 10 игри. Резултата е трагичен. Това е често срещан проблем и разбира се обикновенно ООП е проблемът, а не незнаещия програмист.

Хубавото, че много по-знаещи и можещи хора от Casey са мислили и намерили как може да се реши. За обичащите да четат и учат ето малко повече:
http://www.objectmentor.com/resources/articles/lsp.pdf
https://en.wikipedia.org/wiki/Liskov_su ... _principle

Използвай тези правила и няма да сгрешиш. Или не ползвай ООП. Трудно е да пишеш добър код просто от обща култура. Няма значение дали го компресираш преди или след това.

[KosSiO]

float title_height = draw_title(at_x, at_y, title); <------- това е ужасяващо draw_title кой очаква тва да връща няква височина каква е тая височина, на кого от къде?

какво точно не разбираш от тоя ред специално? това е IMGUI и тези размери може да се генерират/подават насам-натам всеки кадър.

Както казах, не съм сигурен дали твърди че именоването функции му е читаво

Иначе не ми е ясно по същия начин по който и това не ми е ясно.
bool pressed = draw_big_text_button();
От къде на къде draw функция ще връща подобно нещо?

И обикновенно какво става на работа. След M-найстата функция с нелогични параметри/изход решаваш да питаш тоя който е правил тия неща да ти обясни цялостната картинка, ест той ти казва че такава няма сичко е писано в името да няма много код, от където следва че ти тряя да губиш време да цъкаш F12 да гледаш кво прай тая функция + да се абстрахираш от крайно нелогичното име + евентуално да запомниш кое в къв ред тряя да се вика, защото всичко пипа някакви незнайни работи.

[stoiko]

в IMGUI инпута се обработва по време на рисуването

[KosSiO]

в IMGUI инпута се обработва по време на рисуването

възможно, но Draw по никъв начин не подсказва за гетване на Input, поне Update да се казваше. Пък и тва че някой го прави така не значи че е вярно.

[stoiko]

абе заеби името на функцията. човека говори за фундаментални проблеми в писането на софтуер и какво е решението.
Защо вместо за името на функцията draw, не ми разкажеш ти как би направил тази контролка от статията по-добре? ООП? някой дизайн патърн, някоя uml диаграма? някой инструмент за редене на контролките който плюе xml? виждал съм такива домашно сготвени "супер обектно ориентирани multithreaded data driven GUI frameworks" и всичките смърдят лошо.
за принципа на лисков и как кейси не го бил познавал направо не ми се коментира.

[KosSiO]

https://www.youtube.com/watch?v=fj5lE475SVw (е дойде ми времето и на мене да постна нещо мое )

Тук аз и един бивш колега сме направили сички менюта, ОТ-ДО. Играта е freemium и общо взето е с доста повече 'екрани' над стандартните игри със всякакви спешъл евенти, мигалки, контролки и тнт.

На кратко е ще е трудно да го обясня. На кратко артистите редят едни контейнети(които се справят в layout-ите, и контейнерите знаят как да се наместят един друг, ако ти трябва място точно 3 пиксека да кажем, разполагаш нещата в 1 контейнер и там ако искаш може да мажеш колко искаш). След като атриста е изартил всичко. Ние го wrap-ваме в един клас, атриста слага бутончета където му е кеф. Ако някъде трябва динамично да се добавят махат разни неща, през кода всичко е ОК защото описанието се експортва до подходящ формат, и не е много трудно runtime да добавяш махаш компоненти.

Ще кажеш че е мн сложно и тнт, но истината е че не е. Лесно е за промяна защото докато се разработваше играта имаше 5 различни типа менюта, всичко беше пренаправено използвайки базовото. За повече детайли ще ми трябва повечко време, което сега не мога да отделя, ако имате нещо конкретно питайте.

[pdimov]

Тоя bool pressed и мен ме хвърли в музиката леко в началото, но има логика.

[stoiko]

https://www.youtube.com/watch?v=fj5lE475SVw (е дойде ми времето и на мене да постна нещо мое )

Тук аз и един бивш колега сме направили сички менюта, ОТ-ДО. Играта е freemium и общо взето е с доста повече 'екрани' над стандартните игри със всякакви спешъл евенти, мигалки, контролки и тнт.

На кратко е ще е трудно да го обясня. На кратко артистите редят едни контейнети(които се справят в layout-ите, и контейнерите знаят как да се наместят един друг, ако ти трябва място точно 3 пиксека да кажем, разполагаш нещата в 1 контейнер и там ако искаш може да мажеш колко искаш). След като атриста е изартил всичко. Ние го wrap-ваме в един клас, атриста слага бутончета където му е кеф. Ако някъде трябва динамично да се добавят махат разни неща, през кода всичко е ОК защото описанието се експортва до подходящ формат, и не е много трудно runtime да добавяш махаш компоненти.

Ще кажеш че е мн сложно и тнт, но истината е че не е. Лесно е за промяна защото докато се разработваше играта имаше 5 различни типа менюта, всичко беше пренаправено използвайки базовото. За повече детайли ще ми трябва повечко време, което сега не мога да отделя, ако имате нещо конкретно питайте.

точно така си го представих, не знам повече какво да коментирам. контейнери, лейаути и формат на описанието... всичко обвито в OO целофан. чета и плача...

[stoiko]

Тоя bool pressed и мен ме хвърли в музиката леко в началото, но има логика.

ако някой иска ще спретна едно демо на IMGUI. някой, някой? не виждам гора от ръце

[pdimov]

Как обработваш drag в IM GUI? Това, което ми се стори странно в bool pressed не беше това, че го връща draw функция, а това, че моите бутони (както е обичайно) се натискат не моментално на mouse down, а на mouse up, като между двете събития има период, в който бутонът е drag handler, пуснал си е capture на мишката и така нататък. Натискането не е immediate, така да се каже, а deferred. Това за бутон не е особено наложително, но ако имаш спин контрол, който като го драгваш, променя стойността си?

edit: За да е по-точно, той бутонът си се натиска визуално на mouse down, но on click се изпълнява чак като го отпуснеш (ако все още си там с мишката).

[stoiko]

Как обработваш drag в IM GUI? Това, което ми се стори странно в bool pressed не беше това, че го връща draw функция, а това, че моите бутони (както е обичайно) се натискат не моментално на mouse down, а на mouse up, като между двете събития има период, в който бутонът е drag handler, пуснал си е capture на мишката и така нататък. Натискането не е immediate, така да се каже, а deferred. Това за бутон не е особено наложително, но ако имаш спин контрол, който като го драгваш, променя стойността си?

edit: За да е по-точно, той бутонът си се натиска визуално на mouse down, но on click се изпълнява чак като го отпуснеш (ако все още си там с мишката).

в IMGUI контролите имат общо взето 3 положения: НИКАКВО, ГОРЕЩО и АКТИВНО.
НИКАКВИ-те контроли стават ГОРЕЩИ ако да речем мишката е отгоре.
ГОРЕЩИТЕ стават АКТИВНИ ако да речем натиснеш бутон на мишката.
Докато контролката е АКТИВНА, никоя друга контролка не може да бъде АКТИВНА или ГОРЕЩА. (драг?)
АКТИВНИТЕ стават ГОРЕЩИ ако отпуснеш бутона на мишката върху тях и НИКАКВИ, ако отпуснеш някъде другаде.

Моят бутон връща ИСТИНА ако бутона на мишката е бил отпуснат върху него докато той е АКТИВЕН, т.е. работи като твоя.

[KosSiO]

А какво ще стане ако имаш Slide List От елементи един в друг. Да кажем

Хоризонтален слайдър в който има категории състезания. Тия категории състезания са вертикален слайдър със състезания. Накратко слайдър в слайдъра.
В момента в който потребителя пипне екрана кой слайдър е активен?

Има ли някой който казва кой е активен или контролката сама решава че е активна? Ако изкочи поп-ъп че кънекцията е паднала и пръста на потребтеля още е бил в-ху екрана?