What are you working on? V2

[jA_cOp]

[QUOTE=Chandler;16489161]*jealous*

I wish someone would just make a tool so you could flash an SD card to use it. A man can dream though :-/

Also, didn't know you were in Japan. Are you a native or a FES?[/QUOTE]

Well what is a FES?

I'm here for studies.

[Kat of Night]

[QUOTE=jA_cOp;16489474]Well what is a FES?

I'm here for studies.[/QUOTE]

foreign exchange student, and I guess you are if you're there for studies.

[jA_cOp]

[QUOTE=Kat of Night;16489520]foreign exchange student, and I guess you are if you're there for studies.[/QUOTE]

I used to be, but I'm here on my own now :)

[Extrems]

[QUOTE=Chandler;16489161]I wish someone would just make a tool so you could flash an SD card to use it.[/QUOTE]

Only the DSi have an SD card slot.

[Chandler]

[QUOTE=Extrems;16490627]Only the DSi have an SD card slot.[/QUOTE]

ALL DS's have an SD card slot. the DSi does not have a GBA slot.
The SD card slot you're thinking of is one where we can actually put a normal non nintendo-ified SD card. an R4 chip, and other mod chips, are just a modified SD card.

On a side note, I got SDL working with my PSP :c00lbert:

EDIT: Love how I get rated dumb for whatever I say.

DOUBLE EDIT: You guys stay classy.

[Extrems]

Nitro cartridges and SD cards are very different.

[jivemasta]

I'm trying to mess around with extensions for chrome. It can't be too hard since it's only html and javascript. The hard part is going to be coming up with an idea.

[Robber]

[QUOTE=Jallen;16482682]As much as I'd love to get into it, I don't want to risk bricking my PSP.[/QUOTE]
If you have a 1000 or 2000(some of the newer 2000s don't work) you can always unbrick your PSP with a Pandora battery.

[Ddrl46]

[QUOTE=Jallen;16482682]As much as I'd love to get into it, I don't want to risk bricking my PSP.[/QUOTE]
I hacked my PSP 2 days ago, put the battery in + mem stick select M33 wait a few mins and done.

[X-Neon]

Video of my SFML GUI:

[media]http://www.youtube.com/watch?v=YaHXhH-ld_o[/media]

Shows it better than screenshots.

[Nev]

[QUOTE=X-Neon;16496841]Video of my SFML GUI:

[media]http://www.youtube.com/watch?v=YaHXhH-ld_o[/media]

Shows it better than screenshots.[/QUOTE]

Looks pretty cool. How would fading in/out the gradient colors look like?

[X-Neon]

Don't know, pretty similar I guess. I'm pretty bad at coding so it would be more trouble than it's worth for me.

[Jallen]

The window doesn't move to the front when it's moved by the title bar :P

[X-Neon]

Yeah, I need to add that. Not exactly sure how I would go around it though. I was thinking about having a static vector in my button class that points to each button, and will then draw the objects correctly.

[nullsquared]

Just have all the children in an ordered vector. When a child is "active", simply move it to the front of this vector. When you draw all of the children, draw from back to front (so you'd use rbegin(), rend() and reverse_iterator) - this way, the children in the front of the vector will always be on top.

(This is assuming that your windows are indeed a child of some higher widget - in my case, this is an invisible widget called the "sheet")

[X-Neon]

Yeah, I was thinking of having a vector which moves the active window to the front. However, my windows aren't the child of anything, they're just a class so I would need something to reference them by. Also, some of them are declared normally (window MyWindow) and some of them are declared in a vector (vector<window> MyWindowVector) and they are both handled differently, which will make it a headache. I sort of know how I'm going to do it, but the way I've coded it makes it much more effort than should be required

[nullsquared]

[QUOTE=X-Neon;16498174]Yeah, I was thinking of having a vector which moves the active window to the front. However, my windows aren't the child of anything, they're just a class so I would need something to reference them by. Also, some of them are declared normally (window MyWindow) and some of them are declared in a vector (vector<window> MyWindowVector) and they are both handled differently, which will make it a headache. I sort of know how I'm going to do it, but the way I've coded it makes it much more effort than should be required[/QUOTE]

I highly suggest you have a high-level "parent" widget (such as my "sheet") that holds all other widgets (such as windows) which may hold their own children (such as buttons inside windows). This way, your render order system is identical for all cases.

However, in your current case, I'd do something like:
[cpp]
class window;

typedef std::list<window*> windowList;

class window
{
private:
static windowList _windows;
public:
...
};

window::window()
{
...

_windows.push_back(this);
}

window::~window()
{
...

_windows.remove(this);
}

void window::bringToFront()
{
_windows.remove(this);
_windows.push_front(this);
}

void window::renderAllWindows()
{
for (windowList::reverse_iterator i = _windows.rbegin(); i != _windows.rend(); ++i)
(*i)->render();
}
[/cpp]

I still highly suggest you make your windows normal widgets, though.

[X-Neon]

What about windows declared in a vector. Their element constantly change memory addresses, so MyVector.at(1) may be a certain memory address at first, then change later. My assumption that it didn't was what caused this:

[img]http://i29.tinypic.com/71igt1.png[/img]

in the first place

[nullsquared]

I hope you understand that objects stored in a vector will get fully destructed and then full (re) constructed when you do something to the vector. Even if the copied result is identical, it is [b]not[/b] the same instance.

Anyways, since the window vector is static, when you remove a window, its destructor will get called, it'll remove itself from the static list of windows, then when you add a window, it's constructor will get called and it'll add itself to the static list of windows. Ah, the wonders of RAII.

Besides, I don't suggest you do std::vector<window>. Use pointers in this case so adding a window won't recreate all the other windows. Like so:

typedef boost::shared_ptr<window> windowPtr;

typedef std::vector<windowPtr> windowList;

int main()
{
    ...


    windowList windows;

    windows.push_back(windowPtr(new window(...)));
}

[gparent]

In before "boost sukz use raw ptrs and destructors cause thats like no overhead yo".

[jak]

[QUOTE=nullsquared;16499494]I hope you understand that objects stored in a vector will get fully destructed and then full (re) constructed when you do something to the vector. Even if the copied result is identical, it is [b]not[/b] the same instance.[/QUOTE]

Just to clear a few things up, if you pushed a window (an arbitrary class) to a std::vector<window> then all the previously inserted windows are destroyed and recreated?
What if you've modified the position or something, will the variables be kept?

[gparent]

No, but you'll get a bunch of copy construction done in the version depending what you do with it. For instance, pushing back a new window to your vector might cause a capacity increase which will be rather nasty in the copy construction department.

For instance, run this:

[cpp]
#include <vector>
#include <iostream>

struct A
{
A() { std::cout << "A constructed (" << reinterpret_cast<int>(this) << ") \n"; }
A(const A& rhs) { std::cout << "A constructed (" << reinterpret_cast<int>(this) << ") (From Copy: " << reinterpret_cast<int>(&rhs) << ")\n"; }
};

int main()
{
std::vector<A> aVec;
aVec.reserve(4);
std::cout << aVec.capacity() << '\n';

aVec.push_back(A());
aVec.push_back(A());
aVec.push_back(A());
aVec.push_back(A());

aVec.push_back(A());
}
[/cpp]

Once you add that fifth element (assuming your vector implementation gives you a capacity of 4 and not more), you'll be copying the other 4 elements you added beforehand into a whole new memory block.

The same would happen with windows. Several operations can cause movement within the vector, invoking copy constructors like that. Pointers solve this issue.

[jak]

Ah right. So are the constructors and deconstructors called? Surely just copying the bytes would be enough?

[gparent]

[QUOTE=Vampired;16499965]Ah right. So are the constructors and deconstructors called? Surely just copying the bytes would be enough?[/QUOTE]

Maybe you're right, I think I got way mixed up. Give me a sec.

EDIT: Wow. Incoming post rewrite.
EDIT2: Fixed.

[ZomBuster]

Just messing around
[media]http://www.youtube.com/watch?v=F6xFdUpWpbQ[/media]

[Senney]

[QUOTE=ZomBuster;16500418]Just messing around
[media]http://www.youtube.com/watch?v=F6xFdUpWpbQ[/media][/QUOTE]

That's fucking sweet.

[Cathbadh]

[QUOTE=nullsquared;16499494]I hope you understand that objects stored in a vector will get fully destructed and then full (re) constructed when you do something to the vector. Even if the copied result is identical, it is [b]not[/b] the same instance.
[/QUOTE]
I never quite figured out if the resizing operation of the vector is supposed to call the elements destructors or not when clearing the old vector.

[nullsquared]

[QUOTE=Vampired;16499802]Just to clear a few things up, if you pushed a window (an arbitrary class) to a std::vector<window> then all the previously inserted windows are destroyed and recreated?[/quote]
[quote]
What if you've modified the position or something, will the variables be kept?[/QUOTE]
If you've written a copy constructor that does that, yes:

window::window(const window &rhs):
    position(rhs.position) // copy position
{
}

Otherwise, no. (unless you have no copy constructor and the compiler generates one for you, but then pointers will be shallow-copied instead of deep-copied, which is bad)

[editline]01:20PM[/editline]

[QUOTE=Cathbadh;16501120]I never quite figured out if the resizing operation of the vector is supposed to call the elements destructors or not when clearing the old vector.[/QUOTE]

It does.

[editline]01:23PM[/editline]

# is unique id of the current foo:

3 foos:
foo1()
foo2(const foo&)
~foo1()
foo3()
foo4(const foo&)
foo5(const foo&)
~foo2()
~foo3()
foo6()
foo7(const foo&)
foo8(const foo&)
foo9(const foo&)
~foo4()
~foo5()
~foo6()

~vector()
~foo7()
~foo8()
~foo9()

[cpp]
#include <iostream>
#include <vector>

struct foo
{
static unsigned currentFoo;
unsigned id;
foo()
{
id = ++currentFoo;
std::cout << "foo" << id << "()\n";
}
foo(const foo &)
{
id = ++currentFoo;
std::cout << "foo" << id << "(const foo&)\n";
}
~foo()
{
std::cout << "~foo" << id << "()\n";
}
};

unsigned foo::currentFoo = 0;

int main()
{
std::vector<foo> foos;

std::cout << "3 foos:\n";
foos.push_back(foo());
foos.push_back(foo());
foos.push_back(foo());

std::cout << "\n~vector()\n";

return 0;
}
[/cpp]

Notice how when you push 1 foo onto the vector, you get 1 constructor call and N copy-constructor & destructor calls, where N is the previous size of the vector.

[gparent]

Damn, you must've worked on that post a long time since I've posted the same thing 50 minutes ago. (Although I took out the destructors in my case)

EDIT: I mean the code.. of course. The rest I haven't touched fully.

[nullsquared]

[QUOTE=gparent;16501360]Damn, you must've worked on that post a long time since I've posted the same thing 50 minutes ago. (Although I took out the destructors in my case)

EDIT: I mean the code.. of course. The rest I haven't touched fully.[/QUOTE]

No I saw yours but I thought mine showed/explained the situation better.