ב-Online
 
 
 
 
 
 
 
לפרק את הבייט 
ביטים לפנים, אפסים לריסים 
 
 תמונה מתוך דמו    צילום: youtube    
לפרק את הבייט |
 

ב-DemoScene, זירת התיכנות האקסטרימית והאומנותית של עולם המחשבים, תמצאו סרטונים פסיכדליים ב-4K בלבד. עידו גנדל מסביר איך עושים את זה

 
 
 
 
 
 
 
 
 
 
 ככה נראה Intro קדום
  ככה נראה Intro קדום  
 צילום: יוטיוב 
 
פריצה של תוכנות ומשחקים היא לא עניין חדש. העיסוק הלא-חוקי הזה התחיל הרבה לפני האינטרנט המודרני, בימים בהם אפילו BBS היה רק חלום רחוק עבור רובנו. באותה תקופה, רוב הילדים (פרט לעשירים ביותר) פשוט היו מעתיקים משחקים מחבריהם בלי לשאול שאלות, וקיבלו כמובן מאליו שעם הפעלת המשחק, הם יראו מסך פתיחה חביב מטעם פורץ מחשבים אלמוני ונדיב, שבו יוכלו לבחור אינסוף חיים, אנרגיה או כל משאב חיוני אחר לשחקן הרמאי.

מסכי הפתיחה הללו, שנודעו אז לרוב בשם Intro, היו הדרך של אותם פורצי משחקים לפרסם את עצמם ואת יכולות הפריצה והתיכנות העילאיות שלהם – והם הפכו במהרה לשדה קרב תחרותי. אם קבוצת פורצים אחת הציגה את השם שלה קופץ על רקע כוכבים, ברור שהקבוצה המתחרה אינה יכולה להישאר מאחור עם טקסט סטטי: עליה להשוות ביצועים וגם להוסיף ל-Intro שלה משהו עוד יותר מרשים – למשל, מוזיקה. "מירוץ החימוש" הזה התנהל בתנאים מגבילים להחריד: הדיסקטים שהכילו את המשחקים היו בעלי נפח קטן (880 קילובייט במחשבי האמיגה), והיו ממילא דחוסים להתפקע בכל הגרפיקה והתוכנה של המשחק עצמו. לפורצים נותרו קילובייטים ספורים ממש לכווץ לתוכם את ה-Intro המהמם שלהם. המגבלה הזו פסלה מראש כל אפשרות לאחסן סרט אנימציה שלם: מי שרצה להציג תנועה – ומי לא? – חייב היה לחשב אותה בזמן אמת.
 

האקשן מתחיל

 
כאן נכנסה בעיה נוספת לתמונה: המחשבים של אז היו איטיים במידה מגוחכת ממש. המעבדים הנפוצים של היום מהירים מהם פי 300 עד 400 לערך, ומי שרצה לכתוב Intro ראוי לשמו עם אובייקטים תלת ממדיים מסתחררים, מיפוי טקסטורות וכל האפקטים המגניבים האחרים בתוכנה שגודלה קילובייטים ספורים, חייב היה להפוך למתכנת-על. זו אינה הגזמה. ברבות הימים, אמנם, האלגוריתמים נפוצו וכל מתכנת בינוני יכול היה לשלב אותם בתוכניות משלו, אבל האנשים שהמציאו אותם הצליחו לסחוט מהמחשבים העתיקים ביצועים שלא יאומנו. כמו שההאקרים מחפשים פרצות נסתרות במערכות מחשב כדי לחדור אליהן, כך המתכנתים הללו מיצו כל תכונה, כל גרם של יכולת מתועדת ולא-מתועדת במחשבים ההם כדי לבצע מה שנחשב בלתי ניתן לביצוע, ולפוצץ את המתחרים שלהם מקנאה.
 
 
בשלב מסוים הם תפסו את עצמם, הבינו שמה שהם עושים מעניין הרבה יותר מהפריצה למשחקים, והתחילו לכתוב תוכנות Intro עצמאיות. תוכנות אלה כונו לרוב בשם "דמו" (Demo), והתחרות ביניהן הפכה לרשמית לגמרי באירועים המוניים של "סצנת הדמואים" (Demoscene). מטעמים של הרגל ומסורת, התחרויות הללו כוללות עד היום קטגוריות עם הגבלה של גדלי הקבצים – לרוב 4 או 16 קילובייט, לזכר המגבלות הטכניות של ימי ה-Intro. בקישור הזה תוכלו להתרשם מדמו מדהים שנכנס כל כולו בקובץ הרצה של 4 קילובייטים בלבד. רק לשם המחשה, הטקסט שקראתם בכתבה זו עד לרגע זה (לא כולל תמונות) תופס כ-2 קילובייטים שלמים.
 
Demoscene מארגנים תחרויות שנתיות
 Demoscene מארגנים תחרויות שנתיות   צילום: צילומסך 
 

תכנות ללא פשרות?

בתכנות "רגיל", כפי שהוסבר פעמים רבות בטור זה, אנו נתקלים לעתים קרובות בצורך להתפשר על המהירות לצורך החיסכון במקום, או להיפך. בדמו, אין מקום לפשרות כאלה. הכל חייב להיות מהיר, חסכוני ויעיל במאה אחוזים. המחיר הסמוי של תכנות אקסטרימי כזה הוא בספציפיות. לדוגמה, בדמואים שהופקו במחשבי אמיגה, היה אפקט נפוץ של פסים אופקיים צבעוניים שנעו למעלה ולמטה במהירות מסחררת. למה תמיד אופקיים? מפני שאפקט זה הסתמך על תכונה מאד ספציפית של חומרת האמיגה, שלא אפשרה יצירת אפקט זהה עבור פסים אנכיים. כותבי הדמואים יוצרים אשליה משכנעת שהכל אפשרי, אך למעשה הם מציגים רק את הדברים המעטים שבעזרת "קונץ" כלשהו אפשר לבצע בחסכוניות ובמהירות.
 
בחיי היומיום כמעט ואין צורך בתכנות אתגרי שכזה. במידה רבה מדובר באומנות לשמה, ואכן אפשר למצוא בדמואים רבים אלמנטים אומנותיים מאד הן בתכנים והן במוזיקה. יחד עם זאת, קיימים מקרים בהם מתכנת חייב להפיק את המקסימום מחומרה מוגבלת – בעיקר בתכנות של מערכות אוטונומיות וניידות כגון מערכות נשק מתקדמות, חלליות, רובוטים וכו'.
 

אז איך עושים את זה ת'כלס?

מעגלים קונצנטריים בדמו
 מעגלים קונצנטריים בדמו 
 צילום: youtube 
 
בעיקר באמצעות אופטימיזציה מטורפת של הקוד, ובעזרת אלגוריתמים מתמטיים מורכבים ומתוחכמים. בכל מקרה, יש נקודה אחת שחשוב לזכור: זה שהתוכנה עצמה תופסת 4 קילובייטים, לא אומר שהיא לא יכולה להקצות בזמן הריצה כמות ניכרת מזיכרון המחשב! לאור התובנה הזו, בחרתי להתמודד הפעם עם אחד האפקטים הפשוטים יחסית שהופיעו בדמואים ותיקים רבים – מעגלים קונצנטריים משתלבים, דומים במקצת לתמונה שמשמאל שלקוחה מהדמו הפסיכדלי והבלתי-יאומן, לשעתו, State Of The Art.
 
התרשמות ראשונית תעלה מספר אבחנות: יש לנו מוקדים נפרדים של מעגלים קונצנטריים ברווחים שווים, כאשר המעגלים של כל מוקד הם בצבע ספציפי, ואילו החיתוכים של המעגלים מקבלים צבעים אחרים (אך גם הם שיטתיים).

יצירה של מעגלים קונצנטריים אינה מסובכת. ניקח לדוגמה מוקד של מעגלים שרוחבם 5 פיקסלים, עם רווח של 5 פיקסלים ביניהם. ניצור מערך של בייטים, שגודלו כמרחק המקסימלי האפשרי בין שתי נקודות על גבי המסך, ונמלא אותו באפסים ובאחדים לסירוגין, בקבוצות של חמש, כך:

0000011111000001111100000111110000011111...

כעת אפשר לעבור על כל הפיקסלים במסך, לחשב עבור כל אחד מהם את המרחק בינו לבין מוקד העיגולים (בעזרת משפט פיתגורס), ולצבוע אותו בהתאם לבייט המתאים במערך. כך פיקסל שמרחקו מהמוקד 4 ייצבע בצבע "1", ופיקסל שמרחקו 6 ייצבע בצבע "0" (או לא ייצבע כלל).
 
את השיטה הזו אפשר כמובן להרחיב למספר מוקדים בצבעים שונים. עבור כל פיקסל נסכם את הבייטים המתאימים לו בכל אחד מהמערכים השונים ונוכל לקבוע, על סמך הסכום הסופי, באיזה צבע לצבוע אותו. עוד שורות ספורות של קוד יאפשרו לנו להניע את המוקדים בכיוונים שונים על פני המסך, ונוכל להפיק רצף של תמונות נאות כמו זו שלמטה. אבל הבעיה האמיתית עדיין לפנינו: זה יעבוד לאט.
 
מעגלים קונצנטריים תוצרת בית (תכנות וצילומסך: עידו גנדל)
 מעגלים קונצנטריים תוצרת בית (תכנות וצילומסך: עידו גנדל) 
 
הדבר הראשון שצריך לעשות הוא למצוא את הדרך המהירה ביותר לצייר פיקסלים. בעידן Windows, גישה ישירה לזיכרון המסך היא לגמרי לא טריוויאלית. שפת דלפי, למשל, מספקת גישה נוחה מאד לפיקסלים על גבי רכיבים מסוג "בד ציור" (Canvas), אך הגישה הזו איטית מדי בשביל גרפיקה בזמן אמת. נדרשו לא מעט חיפושים כדי לאתר דרך ישירה קצת יותר, שלא ניכנס לפרטיה כאן מחוסר מקום.

ועדיין, יש לנו את בעיית חישובי המרחקים בין הפיקסלים למוקדים השונים. בחישוב על פי משפט פיתגורס לרזולוציה צנועה של 320x200, מדובר ב-64,000 חישובי הכפלה ושורש עבור כל מוקד בכל פריים! כדי לחסוך חישובים אלה, יצרתי מערך דו-ממדי של כל טווח המרחקים האפשרי בין פיקסל למוקד (בציר X ובציר Y), וחישבתי מראש עבור כל תא במערך את הפיתגורס המתאים. זהו חישוב ממושך יחסית אך חד-פעמי, ומעתה והלאה אני צריך רק לדעת מה המרחק בציר X ובציר Y של הפיקסל ממוקד המעגלים כדי לדעת באופן מיידי מה המרחק בין השניים בקו ישר.
 
תוצר של אותו קוד בשינויים קלים (צילומסך: עידו גנדל)
 תוצר של אותו קוד בשינויים קלים (צילומסך: עידו גנדל)   
כדי לגלות את המרחק בציר מסוים צריך לבצע פעולת חיסור וככל הנראה גם פעולה של חישוב ערך מוחלט (כדי להימנע ממרחקים "שליליים"). האם אפשר לחסוך גם את 64,000 הפעולות האלה עבור כל ציר ועבור כל מוקד? בהחלט. אם נבודד את ציר X, קל לראות שעבור כל שורה ושורה במסך, המרחק בין פיקסל נתון למוקד נתון הוא תמיד זהה. אם ערך ה-X של הפיקסל הוא 10 והמוקד נמצא ב-X=50, המרחק ביניהם על ציר X יהיה תמיד 40 ולא משנה מה ה-Y שלהם. אותו הדבר נכון, בהיפוך הסמלים, לציר Y. לכן, החישוב היחיד שצריך לעשות עבור כל פריים חדש הוא של שורת פיקסלים אחת ושל טור פיקסלים אחד בלבד! במסך של 320x200, זה מסתכם ב-520 פעולות חישוב בלבד – פחות ממאית הכמות הקודמת.
 
באופן זה, התוכנה הפשוטה שיצרתי הפיקה בזמן אמת אנימציית מעגלים עם עשרות מוקדים במהירות שגרמה לכאב ראש של ממש – במילים אחרות, במהירות דמו. אך כאמור, זהו אפקט פשוט ובסיסי, והדרך בינו לבין דמו טוב באמת רחוקה מאד. עד שנגיע לשם, אתם מוזמנים להתרשם מאוסף סרטים ביוטיוב שמראים עד לאן אפשר להגיע עם ארבעה קילובייט של קוד, קצת יצירתיות והרבה כשרון תיכנות מהמדרגה הראשונה.
 
 
 
@@@@@@@@@@@@@@@@@@@ ilan @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
@@@@@@@@@@@@@@@@@@@ ilan @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
 
תגובות
הוסף תגובה0 תגובות
הוספת תגובה
מאת
 
נושא
 
תוכן
 
 
 
 
תודה! תגובתך התקבלה.
התגובה תתפרסם בכפוף לתנאי האתר.
 
 
 
 
 

כל הזכויות שמורות 2011 © נענע 10 בע"מ
 
 
 
 
כל הזכויות שמורות © Nana10 בע"מ
Video powered by