Porting to DS

[bullitmagnet]

Hi, I'm not 100% sure this is the right section to make a request, but thought it fit better than anything else.

Is anyone intersted in porting this to the ds at all, or know if its possible. I think the DS is a good platform form a game like this (and should have many games that are similar in its life).

Thanks

[Hythlodaeus]

It certainly is possible, methinks.

[bullitmagnet]

It certainly is possible, methinks.

LOL, cool.... anyone know how one might go about this, i'm just getting into game making and stuff so might take a shot at it, what could possibly go wrong?

[Warboy1982]

i guess the first step would be getting your hands on a DS compiler?

[pmprog]

https://devkitpro.org/

and here's an SDL port
https://gpf.dcemu.co.uk/ndsSDL.php

[bullitmagnet]

bah....thoseare so far beyond my current level of knowlege! I am trying to learn programming and wold love to port to the ds and maybe use bith screens, no idea wht for other than show various bits of info on the top one but yeah....oh well. LOL

[pmprog]

How much programming knowledge do you have?

If you're literally just starting, I'd recommend:

1. Start with a desktop system (Windows or Linux). It's far easier to get into, and debugging is much simplier.
2. Start with a much smaller project
3. Start with a simple language (ie BASIC or python) to learn programming fundamentals, then move on to more complex languages

If you get stuck anywhere, feel free to ask

[goldnux]

Even if this can compile on the DS, it probably wouldn't run at a decent speed, at least not without some work. That said, I've been trying to do this today. So far I've only compiled individual files. Right now my main problem is the lack of openGL, as such. I'm wondering if there's a switch to make it use all SDL instead of openGL?

[Yankes]

OpenGL is used only for resizing and filters, it can be removed without big problems.

[bullitmagnet]

Even if this can compile on the DS, it probably wouldn't run at a decent speed, at least not without some work. That said, I've been trying to do this today. So far I've only compiled individual files. Right now my main problem is the lack of openGL, as such. I'm wondering if there's a switch to make it use all SDL instead of openGL?

Awesome! I have been slowly (very slowly) trying to learn LUA as a language, while it probably wont help me do things with this, I might get a better understanding of programing etc which is something that I really want to do. I would love to help out with this if I can in some way, not sure what but, someway anyway

[goldnux]

If you're not experienced with c++ there's probably not so much you can help with. The DS can be a fun platform to work with, but porting a game to a handheld with such limited resources can be complicated. Thanks though.

Anyway... I've compiled an executable. I did disable the opengl stuff when compiling in ds mode. It displays the "loading..." text on the top screen, though it's extremely squished and unreadable. But there's output on the other screen. Here's what I've got so far:

Code: [Select]

NDS_SetVideoMode
Setting mode 640x4000 (ndsmode 4)
Loading...
Loading ruleset...
std::bad_alloc

bad_alloc means it ran out of memory. The ds has a measly 4 megabytes of memory, and the executable itself has to fit in there. I knew this would be a problem, which is why I compiled everything with the -Os flag (optimize for size). I have an ez-flash 3in1 with 16 extra megabytes of ram, which might be enough. Though I haven't figured out yet how to use this extra memory with malloc() and new.

Oh, and I checked the memory used by openxcom on my computer. 20 megabytes in the main menu. Basically, if this does work, it will probably require the ram expansion.

[SupSuper]

OpenXcom isn't really designed for efficiency so it just loads everything at startup, for something like a DS you would probably need a smarter resource manager to only load what's needed on each screen.

[goldnux]

I should have replied earlier, but I don't think will go anywhere. The ram expansion seems to be limited in that it doesn't support 8-bit writes, that might be screwing things up. And I'm not really interested in reworking memory allocation and all that. I've still got the code if anyone is interested, but it's probably more trouble than it's worth.

[Yankes]

I should have replied earlier, but I don't think will go anywhere. The ram expansion seems to be limited in that it doesn't support 8-bit writes, that might be screwing things up. And I'm not really interested in reworking memory allocation and all that. I've still got the code if anyone is interested, but it's probably more trouble than it's worth.

whole ram cant 8-bit writes? or only part of it? is memcpy forbidden on DS?
I dont see this as blocking problem, its lot less than limitation of 128-bit writes/reads by SSE2 intrinsic
Only place in OpenXcom where 8-bit is require is graphic that in most cases handled by my code.
If I know all limitation maybe I could find some solution that could work around this.

[goldnux]

whole ram cant 8-bit writes? or only part of it? is memcpy forbidden on DS?
I dont see this as blocking problem, its lot less than limitation of 128-bit writes/reads by SSE2 intrinsic
Only place in OpenXcom where 8-bit is require is graphic that in most cases handled by my code.
If I know all limitation maybe I could find some solution that could work around this.

Just the ram expansion doesn't seem to do 8-bit writes properly. So that's 4 megabytes of normal ram, and 16 megabytes which don't do 8-bit writes. This still may not be enough ram without reworking how things are loaded. My life's about to get pretty busy with university and whatnot, so I don't want to spend more time on this.