Hi all,
i'm back and i'm (thankfully) not dead and made it in one piece.
I only did a small update to Oswan (and soon Potator) that makes the menu a little better to control.
I'll have a look at Hugo and strip pretty much everything related to sound, this should provide a
little speedup.
As a long-term project, i'll try to get stripped-down version of Mednafen working with SDL and all
because it has a fast PCE core and it can emulate CD games from iso files unlike Hugo.

I'll improve TX666 as well, if i have any ideas to make it better.
Perhaps i should add more enemies...

Turns out i have some free time before taking the plane so i did a small update.
I have improved the performance and improved the controls.

Quote from: DJ Omnimaga on September 20, 2015, 05:35:13 AM
Also, you should probably name your game Megashark vs Giant Octopus: The Game

Nah, i like my name, maybe you will understand why.

I did a quick fix, one of the sharks could not hit your plane.
dj, pls download it again. (same attachment as before)

Before i leave, i would like to show you this...
It is a little game i made in about 4 hours.


Gameblabla took the plane but he is still not safe !!!
Avoid the flying sharks and discover the truth behind this !

Quote from: DJ Omnimaga on September 19, 2015, 07:07:09 PM
Ooh a PC Engine emu, I'll try it soon. Off-topic question: Is the PC Engine called PC Engine in Europe too? I though it was only in Japan. In United States and Canada, the NEC PC Engine was renamed to Turbografx-16.

It should work on your calc because critor was able to run it on his own Nspire.
I'm warning you though, because it is not that fast.
Europe never had an official release but import copies there were called PC-Engine,
like in Japan.

Quote from: DJ Omnimaga on September 19, 2015, 07:07:09 PM
Also question gameblabla if you don't mind: Where did you live right now? I always wondered since I thought you were always in France, not in another country. ANyway good luck with your move and I hope you can get Internet access and free time again afterward.

Guadeloupe, French Caribeens, i live there.
I hope too i can get Internet access soon after i landed.

I'm trying to make a small game before i'm leaving this place , 2 hours left damnit !

Quote from: Streetwalrus on September 19, 2015, 06:11:48 PM

Quote from: gameblabla on September 19, 2015, 05:46:10 PM
I'll move to france so i may or may not die in the plane.

You're more likely to die once you're there than in the plane. (fun fact: this is actually accurate)

I know... But when bad things happen on the plane,
95% of the time, everyone dies.

So i have fixed Hugo, a NEC PC-ENGINE emulator and it now works properly on Ti Nspire CX.
I suggest you overclock your calc for this one.
(I might look at the frameskipping options later)

You can download it here.
Github repo

Also, it could crash like PicoDrive or the early versions of PocketSNES
so there's no guarantee it will not work on your nspire.

EDIT: Just to warn you that i'll be unavailable from 20th September and this could take days or even weeks.
I'll move to france so i may or may not die in the plane.
In both cases, i have released some of the source code of my broken emulators :

https://github.com/gameblabla/stella-nspire
https://github.com/gameblabla/prosystem-nspire
https://github.com/gameblabla/dgen-nspire
https://github.com/gameblabla/sms-nspire

I have a SMS/GG emulator but guess what ?
It crashes.
I have an Atari 2600 emulator too but guess what ?
It crashes too...
I had (and still have) weird bugs with GCC, especially with optimisations turned on but even without them,
it still crashes for no reason other than bad code being generated by GCC.

Could Clang be used instead of GCC for Nspire dev ?
I heard Clang compiles better code for ARM and that was partly why Apple switched to it.
Anyways, this is the reason why we don't have thousands of emulators for Nspire.

As for z80e, i may give this a look but it looks like it is using cmake... Gee.
I guess i will have to make my own Makefile then.

One more thing : The cause for the slowdowns in Dgen was indeed gettimeday.
It runs much faster but it still is pretty slow (10FPS?) and most importantly,
input does not work on Nspire, even though it does on PC...

Quote from: DJ Omnimaga on September 17, 2015, 10:23:50 PM

Quote from: gameblabla on September 17, 2015, 10:22:15 PM
Now, what happens next ?

Wii U emulator for the TI-Nspire? Some people once implied that its technical specs are inferior to the Gamecube

Lol, i wished they kept its old name (Project Café) because honestly, that's what it's only good for.

Speaking about the 3DO, i found one emulator that was using SDL like one year ago.
Yeah i know, a CD is bigger than the Nspire's NAND but some games are much smaller than that.
Obviously, it will not run fullspeed or even close.
I will into it and see what i can come up with.

I have improved and re-released Where's Derpy for Ti Nspire CX,
a port of a flash game by pepperpunk.
For this new re-release, i have switched to n2DLib and made some minor improvements.
The game is much smaller too and runs faster.


You can download it here.

Quote@gameblabla, congrats, your SNES and Sega Genesis emulators are now on CW headlines.

Yay, i'm on headlines. thx
Now, what happens next ?

The only compiler available for 3DO does support C++ but not C++11.
I told StreetWalrus that using C++11 was not a good idea for portability but they made their decision...
For C++11, i would need to compile at least GCC 4.7 and target arm-coff.
The only other alternative to C/C++ is ARM Assembly and it's a slightly higher revision than the Nspire. (Armv6 vs Arm5vte)

There are still problems with the graphics libraries too.
For example, reusing existant graphics does not work with them, argh...
I think the guy who made the Space Invaders clone for 3DO using my examples found a workaround though...
EDIT: He did not...

If all the mentioned issues are fixed then WalrusRPG should be possible, yes.
The 3DO has 2MB of RAM and 1MB of Video RAM and a resolution of 320x240 for NTSC and 320x288 for PAL.
Hopefully, WalrusRPG will be light on resources...

Quote from: DJ Omnimaga on September 16, 2015, 02:20:46 AM
The lack of enough good 3DO-only games, along with the high price, are what caused the 3DO to sell poorly. It definitively had potential, though, because it had some impressive-looking games even if they were often available on other consoles.

The 3DO Goldstar was much cheaper than the Panasonic ones though.
So cheap in fact that Goldstar at one point sold it for 199$ and lost 100$ on each unit sold !
The 3DO failed mostly because not enough people knew it,
though i agree that the lack of exclusives did not pushed people to buy it.

For example, the Sega CD was much ctier than the 3DO.
It was quite expensive too but despite this, Sega managed to sold 3x times as much units as the 3DO.

Quote
Also the thing is that Road Rash, Samurai Showdown, Street Fighter 2, Wolfeinstein 3D and Bust-a-Move were not exclusives. AN exclusive game is when that game only gets released on 1 single console (for example, Mario Kart 8 with the Wii U and Halo for Xbox). The games above were also available on multiple other consoles that were far more popular (SNES and Sega Genesis, most notably)

The few exclusives by 3DO were not all good, i agree.
Blade Force looks awesome but its gameplay is... hmm.. i don't get it.
Captain Quazar (released very late in the 3DO's lifespan) plays pretty good from what i've seen but it looks like a SNES game.

Also, some games such as Road Rash, StarFighter, Need of Speed, The Horde, Po'Ed and Gex
were released first on 3DO before they were ported to other formats like the PSX and Saturn after the 3DO's demise.

In my opinon, this was a much better attempt to the video game market than the Virtual Boy was.

As for homebrew games on 3DO, i'm pretty much the only guy developping for it.
My best 3DO homebrew game is probably "Unlucky Pony". (the sega cd port i did was not as good as this one)

EDIT by DJ: Topic split from https://codewalr.us/index.php?topic=670.msg22107#msg22107

Quote from: DJ Omnimaga on September 16, 2015, 01:24:29 AM
Also I didn't know you made games for the 3DO. I think there are only 20 official games available for it but I didn't know that console had any homebrew programmers. EDIT Actually it's the Virtual Boy that only had 20 games. The 3DO seems to have many more, except that I heard that only one or two exclusives were good.

Well, i did 3DO homebrew games since 2013, i even ported a CHIP8 emulator to it.
3DO has many games : Sure, not all of them are good but there are some good games on it.
The 3DO, unlike the Sega Saturn and PSX, has no copy protection and it's protection for unlicensed games
has since been cracked. (it was a 256-bits RSA key)

A list  :
Return Fire (my favorite), Road Rash (best road rash), Lucienne's Quest, Samurai Showdown (so good SNK cancelled future ports of Fatal Fury for 3DO),  Super Street Fighter 2 Turbo, Starfighter, Wolfenstein 3D, Bust-A-Move etc...
That's far than "one or two exclusives were good" in my opinion.

(Hopefully my post was not too off-topic)

Quote from: DJ Omnimaga on September 16, 2015, 01:11:28 AM
Would those routines allow him to use actual full screen modes?

It' works with fullscreen modes with no issues but fullscreen is evil, especially on Linux.
This code has no need for fullscreen and my code here actually runs on a window without borders,
which works better on operating systems like most linux distributions.

EDIT: Also matref, i forgot to tell you that but you need to get the bpp using SDL_GetVideoInfo
and you need to use the detected bpp for your RGB Surface and screen surface or else SDL will have to do some conversion,
wasting a lot of cpu cycles.

Matref, there's a reason why things like SDL2 or SDL_gfx exists :
Use them for screen scaling !

For SDL_gfx, it works like this :
You detect the resolution with SDL_GetVideoInfo.
You store the detected resolution somewhere and you tell SDL_SetVideoMode to take all the screen.
Next, you create a RGB Surface with the game's native resolution.
Make sure that your game draws to the RGB Surface instead of the screen.

That's how i do it (the game's native resolution here is 320x240) :

#ifdef SCALING
const SDL_VideoInfo* info = SDL_GetVideoInfo();
scale_w = info->current_w / 320;
scale_h = info->current_h / 240;
 
scale_w_total = scale_w * 320;
scale_h_total = scale_h * 240;

screen_position.x = (info->current_w - scale_w_total)/2;
screen_position.y = (info->current_h - scale_h_total)/2;

real_screen = SDL_SetVideoMode(info->current_w, info->current_h, info->vfmt->BitsPerPixel, SDL_HWSURFACE | SDL_NOFRAME);
screen = SDL_CreateRGBSurface(SDL_HWSURFACE, 320, 240, info->vfmt->BitsPerPixel, 0,0,0,0);
#else
screen = SDL_SetVideoMode(320, 240, 16, SDL_HWSURFACE);
#endif


Then for drawing everything on-screen :

#ifdef SCALING
SDL_Surface* doble;
doble = zoomSurface(screen,scale_w,scale_h,0);
SDL_BlitSurface(doble,NULL,real_screen,&screen_position);
SDL_Flip(real_screen);
SDL_FreeSurface(doble);
#else
SDL_Flip(screen);
#endif


EDIT: My solution here works with all screens but if you like your upscale code better,
it's up to you really.