Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[strainer]

If there may be hundreds of components and their links need recalculated often on the basis of changing relationships, then a carefully designed graphing system is desirable to maintain the links.
But when the links are mostly unchanging, its ok to just have one list of all the component objects (each of which contain individual state info) and one list of all the links between components, each of which has a type which implies what function to apply on the state info of linked components. Updates can be scheduled by just looping through the links . The order of link processing can be randomised and multiplexed to improve integration accuracy if that is needed.

[bloop_bleep]

My system is already implemented as a sort of specialized adjacency-list graph data structure. Components store their Ports inside an std::set, and are responsible for updating and deallocating them. Ports in turn store their Links inside an std::set and are responsible for updating and deallocating them. The System class simply acts as a specialized container/delegator without any actual simulation function.

The TemperatureComponent sort of idea sounds interesting, although of course there is a lot of interdependency between temperature and pressure calculations, so it might be a bit hard to implement.

For a very simple and dangerous solution, you can always push void pointers to things into a collection.  Of course, you'd have to know how to convert them back later, lead to inefficient memory layouts if you're dynamically allocating the items you're inserting, and you wouldn't be able to do it for stack variables that get cleaned up before you use the collection.

I can't think of a reason I'd ever do it, but you technically can.

I'm a bit confused as to in which place this will be used? And also, using this, a problem arises when you have to delete the objects in the collection -- which destructor do you call, if the objects are being stored as void pointers? This can be fixed by using polymorphism to store the destructor inside the vtable, but it involves a lot of extra hassle.

At this point I'm leaning towards just casting the pointers. Type-validity checking can be done pretty easily, and doesn't even need to use RTTI -- I could just implement a get_type() function on Links and Ports that would return "steam" or "electricity" or whatever.

[Telgin]

Sorry, that was just a joking answer to McTravller on how you could slap anything into a collection in C++, even if the types aren't related.  I don't think you'd ever want to do it in real life, and certainly not in your case.

[bloop_bleep]

Alright, I'm using  casts. It's done, it's in there, I'll may or may not regret it later.

Actually, I think I was originally against using casting simply because it was beaten into my brain by many C++ textbooks to NEVER EVER USE CASTS OR GOD WILL KILL A PUPPY ROAARR. If I can be completely certain of type-validity, and casting is much simpler and clearer than the alternatives, there's pretty much no reason not to use it.

Anyway, another small question: is the base class destructor called before, or after, the derived class destructor? Usually base methods are called before derived methods, but the base class acts like a member variable in some ways, and member variables are destroyed after the destructor is called. Hence my confusion.

[bloop_bleep]

Alright, I completed a nice little demo with two SteamPorts connected together, one of which is set to constant 100 pressure using a Boiler component. It even models oscillation correctly -- by the time the free port (the one that isn't connected to the boiler) has reached 100 pressure, the steam already has a certain momentum, meaning that the free port goes above 100 pressure, but then starts losing pressure due to the now backwards pressure difference, then starts gaining it again, etc. Problem is, I think it oscillates too much, since it goes all the way up to 180 and then back down to 20 in the beginning.  Probably just has to do with the values of all the constants in my code; I basically just set them all to 1 because I was too lazy to calculate out the optimal values. I think the oscillation is loss-less, as well, so I should fix that too.

Nevertheless, I still have a working steam demo! Thanks to everyone that helped! 

[Telgin]

Anyway, another small question: is the base class destructor called before, or after, the derived class destructor? Usually base methods are called before derived methods, but the base class acts like a member variable in some ways, and member variables are destroyed after the destructor is called. Hence my confusion.

The base destructor is automatically called after the derived destructor.

I was actually kind of surprised after looking that up, since my hazy recollections on C++ were that virtual constructors and destructors weren't called automatically at all.  I might have to give up the claim that I can program in C++ if I'm getting that rusty, not to mention that the language has evolved so much in the last decade that a modern C++ program doesn't even look like the C++ I learned anymore.

[Urist McScoopbeard]

I'm 100% sure that I did it wrong, but I'm not sure how to do it right. BASICALLY, I'm trying to give this little game physics (not related to previous mapping questions), but uh... it's not working at all. I can't move the sprite at all, it doesn't even fall to the bottom of the screen (which it should be doing). Take a look (please!):

main.py
*It's not throwing an error, the sprite that renders just won't move.

Code: [Select]

#importing stuff
import pygame, render, universal, physics

#basic stuff
pygame.init()
screen1 = universal.BigScreen()
bigphysics = physics.Physics()

done = False
clock = pygame.time.Clock()

#defining stuff
delta = render.Character()
delta.anim("idle", 1)

bigphysics.outputx = 0
bigphysics.outputy = 0


while not done:

    bigphysics.changeinx(0, bigphysics.outputx)
    bigphysics.changeinx(0, bigphysics.outputy)

    screen1.screen.fill((135, 206, 235))
    delta.display(bigphysics.changeinx(0, bigphysics.outputx),bigphysics.changeinx(0, bigphysics.outputy))

    #for doing stuff!
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            done = True
               

    pygame.display.flip()
    clock.tick(60)
render.py
*for loading and displaying animated sprites. Will probably only grow as time goes on to deal with more animations.

Code: [Select]

import pygame, os, universal

screen1 = universal.BigScreen()

#for all animated
class Character(object):
   
    def __init__(self):
        pass
   
    def anim(self, filename, framecount):
        self.filename = filename
        self.framecount = framecount
       
        frames = []
        for frame in range(framecount):
           
            frames.append(pygame.image.load(os.path.expanduser("~/Desktop/pythongame/pygametut/assets/sprites/" + filename + str(frame + 1) + ".png")).convert_alpha())
       
        self.frames = frames
           
    def display(self, y, x):
       
        self.y = y
        self.x = x
       
        for frame in self.frames:
            screen1.screen.blit(frame, (x, y))       
physics.py
*the file in question... it's uh... I don't know. Basically trying to keep keep the physics (however basic atm) out of the main loop.

Code: [Select]

import pygame, universal

screen1 = universal.BigScreen()

class Physics(object):
   
    def __init__(self):
        pass
   
    def changeinx(self, force, currentx):
       
        outputx = currentx
       
        #gravity
        outputx += 10
       
        #jumping
        for event in pygame.event.get():
            if event.type == pygame.K_SPACE:
                outputx -= 20
       
        #bounding   
        if(outputx < 0):
            outputx = 0
        if(outputx > screen1.screenheight):
            outputx = screen1.screenheight - 34
           
        self.outputx = outputx
        return outputx
   
    def changeiny(self, force, currenty):
       
        outputy = currenty
       
        #dashing goes here
       
        #lateral movement
        for event in pygame.event.get():
            if event.type == pygame.K_LEFT:
                outputy -= 1
               
            if event.type == pygame.K_RIGHT:
                outputy += 1
               
        #bounding   
        if(outputy < 0):
            outputy = 0
        if(outputy > universal.BigScreen.screenwidth):
            outputy = universal.BigScreen.screenwidth - 18

        self.outputy = outputy 
        return outputy
universal.py
*basically for any sort of universal constants I may or may not need, and also importing screen rendering abilities to the physics class

Code: [Select]

import pygame

class BigScreen(object):
   
    def __init__(self):
        self.screen = pygame.display.set_mode((750, 750))
        self.screenheight = 750
        self.screenwidth = 750

[strainer]

When writing intricate processes it can be invaluable to include logging of select info and algorithm flow points to illuminate bug searches, off-by-one adjustments, calibration of the buffer sizes and throttles etc.
That can be started in the way of just adding some debug print statements to feel out what is working and find where the first unexepected thing has happened. Simple print statements work. they can grow into more convenient trace logging systems.

A basic debug out helper function can go like:

Code: [Select]

/* psuedocode */
global rundebug=1; //0 for off, 1 minimal, 2 verbose

function debugout( level, infostring ){
    if( level>=rundebug ) outputtolog( infostring )
}

[Urist McScoopbeard]

Thanks, dude... that's actually really helpful to know what's happening!

[strainer]

Welcome - Im always running into things that I cant fathom from reading and a couple of print trace statements later its "ah ha! it was only that there" : )

[bloop_bleep]

There's in fact a 'logging' module in Python that implements this sort of functionality already.

[McTraveller]

You guys haven't lived until you've discovered code behavior that is different when you have debugging printf / logging enabled versus not enabled.

[LoSboccacc]

You guys haven't lived until you've discovered code behavior that is different when you have debugging printf / logging enabled versus not enabled.

damn visual studio debug libraries compiled with non signalling nans, I had to debug that production bug for a week

[strainer]

 >: i n s p e c t  t h e  u n e x p e c t e d :<

edit msg : case and whitespace

[Parsely]

I have a question about HTML+JS. The way we're doing function calls is:

Code: [Select]

var myFunction = function(e) {
  // do stuff
}
But I'm noticing that I'm going to want to reuse some code so I want to use arguments. So I figure I could just do:

Code: [Select]

function myFunction(arg1, arg2) {
  // do stuff using arg1
  // do stuff using arg2
}
But I'm not sure if there is some key difference between these methods that I don't understand, like, maybe hiding the function behind a variable instead of referencing it directly in the HTML is more secure?

I want to be consistent, but I also want to be able to reuse code. Is there a way to do arguments using the first method? Is it okay to mix these two methods? Is there even a difference between these two methods other than semantic?