Use screen.get_width() in a mode


I’d like to use screen.get_width() and screen.get_height() in the of my modes.

It should look like this
import os
import pygame
import pygame.gfxdraw
import random
import time
import math


w1 = screen.get_width()
w2 = screen.get_width() /2
w4 = screen.get_width() /4
w8 = screen.get_width() /8

h1 = screen.get_height()
h2 = screen.get_height() /2
h4 = screen.get_height() /4
h8 = screen.get_height() /8

def setup(screen, etc) :

def draw(screen, etc) :
    color = etc.color_picker()

and so on…

But calling this mode results in an error

    Traceback (most recent call last):
      File "C:\root\ETC_Mother\", line 239, in load_modes
        imp.load_source(mode_name, mode_path)
      File "/usbdrive/Modes/A_Zach_Sine/", line 11, in <module>
        w1 = screen.get_width()
    NameError: name 'screen' is not defined

I don’t understand that, since screen is used in the def statements

screen is getting passed into those functions. try declaring the w and h variables outside, and updating them inside setup as globals:

w1 = 0

def setup(screen, etc):
    global w1
    w1 = screen.get_width()

Hi @oweno,

thanks! That works. The only thing is, that I have to reload the mode one time to set the value from the setup section. Before the reload the variable has the value from the start (in this case 0).

How can I ensure, that the setup part is executed?


setup is called when the mode is initially loaded ( you can see this in
perhaps you are just seeing a quirk when using the editor?

I assume you set all your other vars (w1…w8) in setup too

(you could also use etc.RES[1], but is likely the same issue…)

of course

In fact I run this at the moment on a Windows based version of the ETC program. I didn’t try it on my archlinux laptop or on the ETC-hardware itself.

I’ll try it on the ETC and will report then.


I still had no chance to test this on the ETC itself (its buried in the cases for the live shows), but I found out, that appearently the setup for the last Mode is not executed. If you have only one Mode, then this one is also the last one, and it will have its setup not executed.


1 Like
# run setup functions if modes have them
print "running setup..."
for i in range(0, len(etc.mode_names)-1) :
    print etc.mode_root
    try :
        mode = sys.modules[etc.mode]
    except AttributeError :
        print "mode not found, probably has error"
    try : 
        osd.loading_banner(hwscreen,"Loading " + str(etc.mode) )
        mode.setup(screen, etc)
        etc.memory_used = psutil.virtual_memory()[2]
    except :
        print "error in setup, or setup not found"

yup, it should be

for i in range(0, len(etc.mode_names)) :

seems like only issue with the bug is setup not called, and the memory_used will be wrong
(only a problem if the last mode uses a lot of resources)

fortunately easy fix.
and an easy ‘workaround’, would be to chuck a dummy mode at the end.

Ahh, I should have found that on my own … :wink:

I think that is, why it never became appearent. The last Mode in the delivered default collection is “T Word Bounce” which does not use the setup

1 Like

Ahhhhh!! sorry about that. I remember running across this a while ago. I think it was after we finalized everything, and the solution was just a dummy mode like @thetechnobear suggests. Most of the factory modes don’t actually have anything in the setup function, so it went unnoticed…