What happens when someone with a RPG project and someone with a battle engine project team up?
A new project : WalrusRPG, J-RPG engine for Nspire, by Streetwalrus and Eiyeron (aeTIos is more or less lurking at the moment). Basically, we aim to make a versatile enough RPG engine to create a full game in the vein or Earthbound and Pokemon (each one was the inspiration from both the programmer) on Nspire in C++. A big project starting from scratch but giving us experience on many things we could have missed around on the gamedev subject.
What's the goal? Having a RPG engine versatile enough blahblahblah. For Eiyeron, the main project is giving birth to a game inspired by MOTHER series while keeping its own identity. For Streetwalrus, WalrusRPG is a basis on a project he hasn't really defined at the moment, hence the need for versatility.
What's planned? Well, the points more defined are that we want to have a RPG engine based on an event system, 2-layered tilemaps, HBE as battle engine, the ability to load data from files to allow bigger games, and event scripting with Lua.
What's already done?
Bascially, nothing is in a really done state. But let's check what we already did
- Advanced sprite rendering : based on a Renderer interface, anything aggregating a renderer will be able to draw sprites taken from two kinds of spritesheet : a grid-aligned one (like old Minecraft's item textures) or packed sprites (like modern game engine does, allowing for different sized sprites/frames)
- Time-based animations for sprite rendering.
- Tilemaps. Also as they uses the Renderer and the time-based animations, it allows us to have animated tiles
- Update/Render loop.
- Asynchronous Triple Buffering, because WE CAN DO IT. (and it also helps allowing us squeezing the most FPS we can with vsync).
- A small fixed font renderer. (Also with the SpriteRenderer, we should be able to quickly do a variable-width-height font renderer)
- Automatic compile-time picture to C/C++ data conversion based on ConvertImg.
Soo, we're only a few steps ahead from the starting point but here's the GitHub repo, if anyone is interested in giving us some help on anything about it : https://github.com/Streetwalrus/WalrusRPG .
[spoiler=Old post content]
Quote from: DJ Omnimaga on November 17, 2014, 05:52:30 PM
On a side note, if one day we can manage to do a massive calculator achievement or innovate like Hayleia just did (even if parts of the credits goes to Badja and to a lesser extent Matref for the scaled sprite routine) then we can get more visibility outside the calc world too. :P
Lol yeah, SSBO is really something. We kind of wanted something like that with Pokespire as well. :P
[/spoiler]
Indeed, although I think in order to do it, Pokespire will need to offer something that the GB/GBC/GBA games lack. For example, 3D map engine like in Heartgold/Soulsilver, battle background images (seriously, the lack of battle graphics besides the Pokémons in 1999-2003 was apalling, considering even Final Fantasy I for the NES had battle backgrounds), etc. SSBO for calcs had zooming, which made it stand out from every other calc game, although the hype about it is more because of the Wii U release right now.
EDIT: The inviting has slowly started. Keoni29 is the only member approved so far, though. Make sure to ask permission before approving users, in case somebody finds us and he is not part of the invited group.
3D backgrounds are impossible lol but we're aiming for a slight improvement over GBA graphics and a gen4 style battle engine.
I think pseudo 3D could be done since HP PPL can do it, but it would obviously not run at 60 FPS unless you wrote a good scaled image and ran at 160x120 or something:
(http://img.ourl.ca//hpprime3dupdate.gif) (http://img.ourl.ca//fireeffect.gif)
Basically, the stuff displaying on top of the other layers could be leaves, while the layers below could just be circular brown shapes that makes trees up. It would be best to pre-render the layers if they are scaled up, though, for faster speed.
So yeah, subforum.
Splitting some discussion from the staff board. :P
To reply to DJ, keep in mind that the Nspire is 3 times slower than the Prime and we already have enough trouble keeping the framerate up to add this.
Yay for subforum! By the way, is the name final? I'll need to create an icon.
As for Nspire speed, to be honest I am a bit surprised that frame rate is an issue considering what the SNES and Sega Genesis could do. I mean, those consoles were not even close to 150 MHz, yet they still pulled 60 FPS parallax scrolling maps. I know the Nspire lacks a GPU and stuff but still... That said, I am fine if a game runs at 24-30 FPS and it's probably best that on Clickpad/Touchpad models it won't run higher than 15 FPS.
Also the HP PPL language is a proprietary (although compiled) language which is most likely much slower than C and ASM, unless HP really pulled a miracle on it. But yeah I am kinda surprised that Ndless programs have some frame rate issues considering what the SNES, Sega
Quote from: DJ Omnimaga on November 18, 2014, 10:24:16 PM
As for Nspire speed, to be honest I am a bit surprised that frame rate is an issue considering what the SNES and Sega Genesis could do. I mean, those consoles were not even close to 150 MHz, yet they still pulled 60 FPS parallax scrolling maps. I know the Nspire lacks a GPU and stuff but still... That said, I am fine if a game runs at 24-30 FPS and it's probably best that on Clickpad/Touchpad models it won't run higher than 15 FPS.
That's exactly the issue. The lack of a PPU is the most limiting factor for me. Also we currently don't plan to support classic calcs unless we can somehow fit the game into the flash (it's gonna have a ton of assets to load).
Also, the name is more or less final as far as the engine is concerned. The final games (we're probably make a Nintendo-style dual release) will be called Pokemon <stuff>. :)
Don't expect the classic models to be supported anytime soon, from our calculations the game is going to be ~20MB just like the gen III games.
I guess it's fine considering for such large game it's justified.
Quote from: aeTIos on November 19, 2014, 07:01:23 AM
Don't expect the classic models to be supported anytime soon, from our calculations the game is going to be ~20MB just like the gen III games.
That's actually bigger than gen III games. Considering that the GBA uses thumb (which may or may not reduce executable size) and we use regular arm (16 bit vs 32 bit instruction sets, doesn't change the fact that the cpu is 32 bit), and we use higher resolution everything we are highly likely to exceed the original's 16MB indeed.
By the way, what sprite size do you use?
Tiles are 24*24, the rest is undefined for now.
Ah ok thanks for the info. This should be interesting :)
Yup. I think you can basically take GBA sprite sizes and multiply them by 1.5 since the Nspire's resolution is 1.333 times that of the GBA horizontally and 1.5 vertically.
Yeah, but don't just take the original graphics then resize them, else it will look ugly XD (I think I saw that in commercial remakes before). Brand new graphics or ones adapted to the new res would be nice. ;)
He was talking about taking the sprite *sizes* and multiplying them by 1.5, not the actual sprites ;)
Also @street I wonder if this gonna go somewhere if you are going to do as you said and drop the nspire once you get a prime >_>
I think you should still continue the Nspire version. D:
Quote from: DJ Omnimaga on November 20, 2014, 09:33:59 PM
I think you should still continue the Nspire version. D:
I also think so :| Mostly because there are way more ndlessed calcs than there are people using the Prime.
Yeah I agree. Maybe both versions could be made at once?
I'll leave that for when it happens. It'll be a long time before we are actually going to code on this, anyway. I first want to make some other things, to get better and C and to release stuff :P
I decided to go cross platform, but I still want to use the Prime to it's full capabilities so it may have extra features on there than on the Nspire (I can already tell you that graphics will be much smoother and maybe have more effects). Figuring out how to make the game compile for both calcs from the same code base is to going to be a nice challenge.
Ah ok, I guess it's fine then. THe thing is that the Nspire userbase is far larger than the Prime. That said, in my case I only really do stuff for the Prime and not the Nspire since I prefer HP PPL language.
Well I kind of want to give the Prime a kick start. :P It'll be hard but if we can attract Ndless devs then that's already half of the battle to make it popular.
Quote from: DJ Omnimaga on November 18, 2014, 02:50:26 AM
I think pseudo 3D could be done since HP PPL can do it, but it would obviously not run at 60 FPS unless you wrote a good scaled image and ran at 160x120 or something:
(http://img.ourl.ca//hpprime3dupdate.gif) (http://img.ourl.ca//fireeffect.gif)
Basically, the stuff displaying on top of the other layers could be leaves, while the layers below could just be circular brown shapes that makes trees up. It would be best to pre-render the layers if they are scaled up, though, for faster speed.
Ahem. I have a Mode7 library for Casio. A little tweaking and it could run on Nspire :-°
Oh and I have some leftovers from a battle engine attempt for Prizms. Maybe you want to read them.
Problem number 1 on the Nspire is the slow memory bus. z80/68k/SH-3/4 calcs don't really have this issue as they have memory faster than what the CPU can put out (SRAM) while the CX (not the Classic as it has a twice faster memory bus) is limited by it's 60MHz bus. <_<
A test should be done to benchmark that thing. It looks like.a real power waste when you see this CPU/memory speed ratio...
Quote from: Streetwalrus on November 25, 2014, 09:56:38 AM
Problem number 1 on the Nspire is the slow memory bus. z80/68k/SH-3/4 calcs don't really have this issue as they have memory faster than what the CPU can put out (SRAM) while the CX (not the Classic as it has a twice faster memory bus) is limited by it's 60MHz bus. <_<
Do you mean the AHB? Cuz that seemed to be an issue in nKaruga at first. It's a shame considering the calc is 150+ MHz and $170 x.x
Also how the hell can TI downgrade their calcs like this when moving to color screens? With the CSE they didn't downgrade physically, but they added nothing to accomodate the larger screen and the result is a much slower calc (although still way faster than the ClassPad II and some PRIZM BASIC). I bet if they ever make a calc with the speed of the Clickpad memory bus but a CX screen, they'll use that excuse to jack the price up... <_<
Well besides compiler optimization the only way I had to speed it up was to implement a frame skipper (not that it's a bad thing for now but I fear some things will slow it down <_<).
By the way, what is the exact frame rate you get in this game when the character walks around on scrolling maps, if you only update the tile row you're scrolling towards to? And what is the frame rate if you redraw the entire screen every frame?
Hmmm. You're probably gonna think I'm a freak but I get like 30fps or so for now though it's gonna drop pretty soon.
30 fps doesn't seem too bad actually for a calc. But yeah if it drops at like 15 fps it could annoy some players. 20-24 would probably be fine for everyone or at least tolerated by Call of Duty and Crysis fans. A lot of people can't even run recent computer games above 20 FPS at minimum settings anyway.
EDIT: In fact I heard once that it's under 12 FPS that a video really starts to get unwatchable. Of course for action games that would affect gameplay but for an RPG, if people are fine with watching choppy Youtube videos with horrible compression, then I don't see why they should have a problem with even 12 FPS in a tilemapped turn-based RPG.
30 fps? Butdoes nkaruga runs smoother than that? I feel we're getting a similar problem than the Prizm.
Well, I spent quite some time reducing CPU load from hungry sources. For example n2dlib uses buffer copying which is incredibly inefficient when you redraw the whole screen every frame like I do, so my graphics module implements buffer swapping. I should probably learn how to use interrupts to avoid stalling the whole thing when doing vsync (which I also implemented myself as n2dlib doesn't do it). I also enabled -Ofast compiler optimizations right from the start (when I realized that I still had -Os in my Makefile that is), so that we get an executable that runs as efficiently as possible and to avoid having to deal with a cload of bugs if we were to enable it later than now.
The map renderer is still not complete as we need 3 layers + object and NPC rendering to accurately reproduce the Pokémon gen-III mapper. This is the kind of stuff that will definitely slow down rendering so I'll see what I can do about it. Since I redraw the whole screen, animated tiles are basically free. :)
We're very likely to recommend overclocking for this game although it won't be necessary (just so that the framerate stays smooth, I develop on my calc running at 246MHz and aeTIos's runs at 252).
The problem we have is not refreshing the whole buffer every time but handling a huge amount of sprites (we draw a 15x11 chunk of the map, with some tiles being multi layer and NPCs, the character, weather effects... that's about 400 sprites every frame under spike load).
That's pretty hardcore. Why not storing static parts a bigger bitmap? It would decrease the blit overhead at the trade of memory.
Believe me, we already considered it. That alone is one of the reasons why we dropped monochrome models. They don't have nearly enough RAM for that. Maybe if we were to tell the os to c off and force a reset on exit then we could program the calc down to the metal. But that would be too much of a pain. Also consider that a 100x100 map prerendered as bitmap would use about 11MB of RAM while we could use it for something else (iirc there's ~4MB free on the classic, +32MB on the CX). And that's without animated tiles. While it would drop about 200 to 300 sprites per frame, this is a massive tradeoff that will only be accepted if it's absolutely necessary and it actually fits in RAM (we might have to use the aforementioned hack to use the full 64MB sdram that the CX sports).
As you can see these measures are pretty extreme so let's do our best to avoid them. Should allow the game to run at 60fps though. :P
Oh wow I didn't realize you needed three mappers O.O. Now that explains why it won't be as fast. I was thinking with 1 layer plus some sprites in mind at first. On the other hand, the extra effects and stuff will definitively spice the game up. :)
Good luck!
Well I could take some other shortcuts to speed up the mapper like caching layered tiles and weather effects which will use way less RAM and get me to about 200 sprites per frame (that's giving myself a lot of headroom - if we reach 175 then it means there's a cload of NPCs lol).
110 * 110. But even the DS loaded smaller maps than that! Just load map chunks, that'll (maybe) less heavy on the ram, won't it be?
We could render the back layer at runtime and shift it, but I have no idea how any of that works in C.
Loading the entire map to avoid having to render it in real time would definitively help, but that requires a crapload of RAM during execution, which could cause some problems for people who got a lot of ROMs and mViewer stuff on their calc.
Eiyeron that could work, I'm taking note here.
aeTIos : We need to prerender all three layers at the same time, x4 or so because of animations, not because of multiple layers. As for shifting around the picture, it's really simple.
DJ : I don't see how having many files would cause any problems. The filesystem is in flash after all.
Oh wait I forgot that on the Nspire, executable files aren't stored in RAM. I know the OS is copied to RAM on boot or something but I forgot that it was different for the documents.
But yeah, if a map is 128x128 tiles and you pre-render it, then you need like 38 MB of RAM assuming it's 16-bit and 19 if it's 8. Even moreso if you have three layers (in such case you won't even have enough free RAM if the three images are 16 bits.)
the layers just render to the same buffer. It would be silly to render them separately.
Blit all the subblitals? Maybe the most unefficientvway of doing it z unless some animations spend on only one layer...
I didn't really understand that post. :P
I hate touchscreen keyboards. I meant that having buffers to manage each layer independently from their positions is only useful when managing one layer animations.
Quote from: Streetwalrus on November 28, 2014, 08:55:58 AM
the layers just render to the same buffer. It would be silly to render them separately.
Oh ok I thought you needed them separate for when characters walk behind trees, houses, etc.
We can just draw one tile on top of the character in that case.
I had an idea to reduce the amount of sprites drawn. If I understand correctly, you draw the whole tilemap once for each layer ? If yes, only draw what's certain to be visible on-screen (I know you already do that, but it doesn't hurt to remind it). Then, I see from your code that you draw tiles regardless of their layer level ; no wonder that you draw > 300 sprites each frame. So here's what I propose :
Basically, have each tile be a structure, ordered like so :
typedef struct
{
uint16_t **imgs; // or a reference ID if you have a big map, but this makes it so you don't need lookup as much
int usesLayer[MAX_LAYERS]; // ints are much faster than anything else on Nspire ; you should remember this for the future
// maybe more, what do I know
} tile_t;
The trick is that usesLayer is an array of boolean values. To use that, you'll have to modify your map drawing a bit : you must know exactly what layer you're currently drawing, that way you can just test the corresponding entry in the usesLayer array of every tile_t structure you've got and ignore them if you find a 0 value. That should actually cut off more than 50% of the drawables, since most of them aren't animated (correct me if I'm wrong).
Hmmm, I removed the multi layer code for now but I actually test if a tile is 0 (transparent) on the upper layer which greatly speed up rendering but it does slow down if there are many tiles on them.
I remember chatting with you guys about this project on HCWP a few weeks ago. It's a really ambitious project, and I'm really interested to see where it goes. :) Can't wait to see some screens.
I should make an animated screenshot of the current tilemapper. Need to find more awesome ways to make it faster too.
If you pre-render an entire map then only draw a 320x240 area of the resulting large pic, is it much faster? On the Prime that seems to be the way to do it in order to gain speed, else you can shift the screen content then draw the missing row of tiles, although it's harder.
I wonder what everyone wants to see first? Also, I probably will need help with spriting. I can only do so much, especially with college up my back.
Maybe start with battles first to ensure you can pull such thing off and work on the menu. Make sure to plan variable management ahead, though.
Quote from: DJ Omnimaga on January 03, 2015, 11:11:21 PM
If you pre-render an entire map then only draw a 320x240 area of the resulting large pic, is it much faster? On the Prime that seems to be the way to do it in order to gain speed, else you can shift the screen content then draw the missing row of tiles, although it's harder.
Well, it's definitely an insane amount faster to do, but it would require insane amounts of ram. So much that I may need to kill TI os at one point. Besides it's already been discussed. :P
Also variable management is a non issue in c. Since you give names to every variable, and you have an unlimited amount you can do it more easily.
Yeah, on the HP Prime, using pictures this large seems to cause stability issues. <_< That said I found an alternate solution in my case which I'll post in my SWL thread.
As for variable management, I meant you should make sure to comment the code or a txt plan file so that you can remember what each variable did in the future, should you take a very long break from this project. Even with names it can still get confusing when you have 100-200 variables.
Yeah I make sure to comment every variable and everytime I come back I check if I still understand what stuff does and if I don't I figure it out and improve the description.
Hmmm functional programming really helps. I use self-explanatory function and variable names, and there's not many variables per function so it's easy enough.
THE GAME
I'm picking this back up. I'm currently in the process of refactoring the engine in order to streamline development. Considering switching to C++. Eiyeron is helping me now and is going to contribute to the code.
The name was changed to WalrusRPG because this is no longer a Pokemon clone (until further notice :P). New repo URL : https://github.com/Streetwalrus/WalrusRPG.
Aaaand an update already ! :D
Eiyeron worked (blindly as he couldn't compile the project yet) on reorganizing the source for the C++ conversion. I just spent a few hours getting it up and running. The new code is in the cpp branch, and ready to be merged into master once we decide we're happy with it.
GLad that this is being revived. I hope it eventuyally come to fruition. I think it's better if it's just a generic RPG engine rather than a Pokémon game, since it gives you more freedom and you can start smaller. Maybe the engine could be used to port certain games?
Also since you use 24x24 graphics, Walrii could fit perfectly. :P
Quote from: DJ Omnimaga on April 30, 2015, 07:21:47 PM
Also since you use 24x24 graphics, Walrii could fit perfectly. :P
Actually you just gave me an idea for the test sprites. :walrii:
Or they could be permanent :trollface:
Seriously, though, at one point there needs to be a Mario-style RPG where every single character is a walrus, except maybe the final boss unless that boss is Dark Walrii :P
Anyway good luck with your engine. :)
Which kind of Mario RPG? Classic like Square did with SM RPG or the action command-based like M&L series or Paper Mario series? The latter is a bit harder to set as it'd need to manage real time events.
Yeah I mean SMRPG style in terms of theme, but perhaps closer to SMB themes. Basically all I mean is that a Walrii-based RPG would feature a story where a princess gets captured and it would not be even close to a dark story (except maybe the intro)
Updated the source code to fix map's rendering code. Bad math caused to have curious reactions and crashes when going outside of the map. Never trust user input.
Well I was aware of this. I took the checks out cause I planned it with the maps having enough padding for that not to happen in mind.
Never trust user input. For instance gen I Pokemon games crashed when an user cheated to get outside of the map. The gen IV sinec platinium blocks the player when he gets outside of the map by TT (on D/P, you could navigate more or less without problems in the RAM and getting to places you shoudln't be without triggering certain events).
Edit : Added a Pixel class. This made me love C++, for that part
/*
* Pixel structure
*/
class Pixel {
union {
std::uint16_t value;
public: // hack to be able to do pixel.r. Clever!
struct {
unsigned r : 5;
unsigned g : 6;
unsigned b : 5;
};
};
You can have parts of a structure/union public and the rest private. This just made my evening. :3 The rest of this class is pure stupids things like operator= override or constructors by copy/passing 1 or three arguments for color. I'm starting to love c++.
Quote from: Duke "Tape" Eiyeron on May 09, 2015, 07:55:24 PM
Never trust user input. For instance gen I Pokemon games crashed when an user cheated to get outside of the map. The gen IV sinec platinium blocks the player when he gets outside of the map by TT (on D/P, you could navigate more or less without problems in the RAM and getting to places you shoudln't be without triggering certain events).
I think that most old games only take into account user input from players who don't cheat nor abuse glitches, so developers might see anything more complex as unnecessary.
Yeah, games aren't designed to be hacked or glitched in the first place. :P
On a side note, since I cannot test on-calc right now, how is the speed so far?
It's pretty fast thankfully. Without the frame regulator it goes way above 60fps :3
Quote from: Streetwalrus on May 10, 2015, 06:52:33 AM
Yeah, games aren't designed to be hacked or glitched in the first place. :P
Hmmm...
Now i want to make a game that the purpose is to glitch/hack it. :P
Heh, that would be fun. :P
But it would need good graphics. Maybe a minecraft mod...
anyways, back on topic.
Note for self : don't use C++'s streams. TO just show camera's coords, this makes the binary size jumps from 68 kB to a whopping 1MB because I wanted to do
ostringstream flux;
flux << "X: " << camera.get_x() << " Y: " << camera.get_y();
print_string(flux.str().c_str(), 0, 8);
But with sprintf, I just got only to 100KB. Welp...
Edit : Added support for tilesets from different sizes. The current builds are built with a 24*24 and a 16*16 tileset and respective maps to show how the map engine stills goes smoothly with that.
Quote from: Unicorn on May 10, 2015, 06:58:00 AM
Quote from: Streetwalrus on May 10, 2015, 06:52:33 AM
Yeah, games aren't designed to be hacked or glitched in the first place. :P
Hmmm...
Now i want to make a game that the purpose is to glitch/hack it. :P
Maybe Streetwalrus could make WalrusRPG as an action RPG but where every NPC and enemy acts like if they were tool-assisted and performed thoughts and actions frame by frame instead of in real-time. There could be plenty of references to popular TASes on Youtube/TASVideos such as glitch abuse. :P
Okay, we did olots of progress. We got rid off of C++'s STL to use a tiny one (aptly named tinystl) and we're using zlib exec compression. Thus we only have now to transfer a 65KB program instead of a 1MB one! \o/
Awesome to hear. :D Also 1 MB would fill the calc very fast for 3.9 users O.O
Yeah, even though Street aims only the CX, being able to run it on legacy nspires could be cool. We'll probably use conditionnal compilation to build two versions to help size diwn the legacy builds and improve lisibiliy (because, dang, gray on gray doesn't help)
Cross compatibility can be done with 100% runtime stuff. The main obstacle would be RAM usage, so we'll see how it goes. The uncompressed executable + all the runtime data need to fit in the low amount of free ram that the monochrome and CM calcs have.
I wonder if old Nspires can be downgraded from OS 3.9? Because I doubt an RPG will run on those calcs if they run OS 3.9. 3.9 leaves them about 2-3 MB of memory at most because it's so large, so you would have to advise people to downgrade to 3.1 or 3.6, if possible.
2-3MB of ram or flash ? And on the classic or CX ? We're primarily targeting the CX which should have plenty of memory.
Quote from: Streetwalrus on May 14, 2015, 09:17:40 AM
Cross compatibility can be done with 100% runtime stuff.
Yeah, like this we will have a bloated binary with both functions for the legacy nspire? Nah, it's not really a good idea (but well, the legacy having more memroy, I would have also chosen this option).
That's true. The necessary code to have it work on both calcs isn't much tho, just a different timer and LCD driver so far. The keypad is already handled by libndls.
Quote from: Streetwalrus on May 15, 2015, 02:58:33 PM
2-3MB of ram or flash ? And on the classic or CX ? We're primarily targeting the CX which should have plenty of memory.
Yeah I meant the classic ones. OS 3.9 is so large that on classic models it only leaves about 2-3 MB of user RAM and archive. This is why OS 4.0 is CX-only, as it no longer fits on grayscale models. I was pointing out, because if you decide to make WalrusRPG compatible with them as suggested above, then you would probably need to put a warning in the readme suggesting to downgrade.
For RAM it's been this way for ages. For flash it's unexpected but either was gonna kill portability at one point. Unless we do dynamic memory management right.
I thought that back in the days we had like 17 MB of free RAM with OS 2.1 and stuff? ??? And yeah personally you should worry about getting the engine and game to run on the CX. After all, the grayscale models were discontinued over 4 years ago so game popularity on them will most likely be like on the TI-82 and 86 soon.
Is it like samsung devices where every update and new phone has more and more bloatware?
Not bloatware, but more features, so there is less and less space on each update. Some people also believe that the OS is very unoptimized and that Nspire OS 2.1 could be optimized so much that it could actually be ported to the TI-84 Plus Silver Edition and take the entire 2 MB Flash memory (or close).
Work has been done to improve the way WRPG will render things.
An abstract class, Renderer, is the parent of two classes, SpriteRenderer, future class to allow rendering sprites packed in textures like if they were with Texture Packer (https://www.codeandweb.com/texturepacker), and TileRenderer which does the good old "take a sprite from a grid and blit it".
So, to animate the while thing, the animation code has been put out Tileset to become a full independant class which only job to store animations and return the correct frame after time updates.
A bit more classes, but these ones are better structured and more SOLID-like. Cool.
Aweome to see updates. How is the scrolling speed so far? (I remember that nKaruga had speed issues at first on color models)
Well, it's coming smooth. We limited the FPS to vsync because we have problems if vsync is turned off. I think it goes around 57 FPS (slight hiccups because vsync precision). Also with a bunch of text it still goes fine.
Woah that's fast!! *.*
Yup, the game still runs at 60 fps. I'll try to see if it drops any frames.
Edit: I actually made a framerate meter, the game runs at a little less than 30 fps which is still very good. Since frameskip is implemented it's pretty much perfect. The loop is entirely regulated by a hardware timer so it runs at constant speed even with frame drops.
So you can for example increase it to 60 fps too? :P
Well the game runs at 60 updates per second, it's just that the renderer is too slow to keep up (besides it's a single threaded engine).
I guess it's better that it runs at around 30 FPS. After all, I bet that most emulators have frame skipping anyway and perhaps the LCD will skip frames if the frame rate is too high (kinda like the HP Prime).
Oh well, we'll have to see for later for performance. We can't really do better at this moment as the nspire doesn't look like having a physical blitter onboard. :/
Quote from: DJ Omnimaga on June 26, 2015, 04:50:45 AM
I guess it's better that it runs at around 30 FPS. After all, I bet that most emulators have frame skipping anyway and perhaps the LCD will skip frames if the frame rate is too high (kinda like the HP Prime).
No it won't. It refreshes at 60fps period. And we have full control over it too unlike PPL (since we access the hardware directly).
Fwiw, we tried lifting vsync out and we get 52-55fps so I'm gonna take a stab at triple buffering with the vsync interrupt to see if it improves performance at all (which it should, in fact it will probably reach these 52-55fps all the time).
Is there a lot of tearing/distortion when scrolling around?
Without vsync there is tearing when we clear the screen before drawing something. With, no problem
Without vsync it's seizure mode. :P
Just implemented triple buffering, now turning off vsync is seizure-free.
Screenshot of the beast :
(https://sr.ht/9137.jpg)
The framerate is almost double of what we get with blocking vsync. Once I implement it with an interrupt it will actually render this fast and also push it to the screen as fast.
Also the graphics are 16x16 placeholders, we intend to use 24x24 for the actual game. Water tiles are animated but that's not visible on the screenie.
Beautiful. Did you make those sprites by tge way or are they from a game or RPG maker? Looks very SNES-like. They could be re-used in another game.
That looks quite awsome
I, unshamely, found them on OpenGameArt and used them.
OGA is awesome though (i saw the snake :3)
Update : https://github.com/WalrusRPG/WalrusRPG/commit/b4a480bb77d490d99f4c63ca0eb686ec83fcd9d1
Nuff said.
Snapshot build attached.
Warnings :
-It will not work on black and white calculators, don't even try. It may work on the CM but we don't have any to test with, only CXes on which it runs perfectly.
-You need an up to date version of Ndless to run it, I attached the latest version built from git so that you guys can update. It should work with 3.1-3.9 inclusive. 3.1 may require Nlaunchy, I never used Ndless without it so I can't say. To update just replace your ndless_resources file with the new one.
-As always with development snapshots, it may be dangerous so make sure to back up your stuff ! We don't touch files yet so it should be rather safe and the app should be crash free because of all the testing, but be careful.
Cool! Too bad i don't have an nspire :/
Quote from: Streetwalrus on June 29, 2015, 10:17:49 PM
Update : https://github.com/WalrusRPG/WalrusRPG/commit/b4a480bb77d490d99f4c63ca0eb686ec83fcd9d1
Nuff said.
Beta build attached.
Warnings :
-It will not work on black and white calculators, don't even try. It may work on the CM but we don't have any to test with, only CXes on which it runs perfectly.
-You need an up to date version of Ndless to run it, I attached the latest version built from git so that you guys can update. It should work with 3.1-3.9 inclusive. 3.1 may require Nlaunchy, I never used Ndless without it so I can't say. To update just replace your ndless_resources file with the new one.
-As always with development snapshots, it may be dangerous so make sure to back up your stuff ! We don't touch files yet so it should be rather safe and the app should be crash free because of all the testing, but be careful.
Beta? No. Let's dig into the common "alpha/beta" name designations
- Alpha usually means that a part of the engine is done, the game is playable but you'll uickly see that it's not finished at all
- Beta is usually used when the core engine is mostly done and work is done on it but mainly the surrounding features or gameplay.
We ain't even in alpha, d00d, we've just started the thing! :p
Changed for snapshot. :P We already have a pretty solid base though. With the current components we can stitch together the rest of the overworld module pretty easily now.
Don't forget that a map can change according to the local/global events (like a bridge falling or a region changed). Swapping a map fdor another for each kind of event will not be a good thing as if a map does has multiple evetns, we have to put each change combination in the data.
Yeah, event system is left to do.
A lot of things are left to do, actually. :p
Just to know, since I'll need it for my pokemon too and I don't have any ideas yet... How will your event system be made? The easiest thing would be to hard-code events, but that's definitely NOT the right approach 9_9
Ooh I'll try this soon. I don't think my version of Ndless is up to date, though, so I'll have to find some time to update first. I don't have nLaunchy either.
Quote from: p4nix on June 30, 2015, 02:48:11 PM
Just to know, since I'll need it for my pokemon too and I don't have any ideas yet... How will your event system be made? The easiest thing would be to hard-code events, but that's definitely NOT the right approach 9_9
Actually I don't think WalrusRPG is a Pokémon game anymore. Perhaps he had some stuff planned, though, before he put the Pokémon game on hold and turned it into WalrusRPG engine, though.
Well it's still an RPG engine, Pokémon or not but I don't know if our stuff will be useful to you since it's all C++, and we use it extensively.
Also DJ, I'm not sure that you actually need Nlaunchy to update ndless. Try to just replace the ndless_resources file and if it doesn't work I'll help you get nlaunchy set up.
Reuben Quest :P
And I'll try. As long as I don't have to re-install Ndless from scratch, since that requires like 100% battery (since TI-Nspire Student Software is a c about battery requirements to transfer .tco files.
Just leave the calc plugged in for 24h :P Mine is always charged cause I leave it plugged into my PC for programming. You should use the computer link software or tilp tho. :P The student software is a piece of trash, I couldn't even activate my copy. >.>
Streetwalrus, maybe you should update the first post with a link to the GitHub or something :P
Yeah I should rewrite the first post entirely. :P
Started editing it, because I can do it. :p YOu should do some format and puts screens if you want to, Street.
So in addition to last week's work I did to restructure the engine in a more manageable way, I completely reorganized the repo and reworked the build system today. It's still in a separate branch but as soon as I'm done with the build system improvements and @Eiyeron approves, it's good to merge.
Awesome. I can't wait to try the new version. :)
Nothing visibly changed. :P The stuff I did was mostly so that writing and maintaining the code is easier.
Ah I see. I thought that almost the entire game was done.
Just kidding, take your time :), I am really curious about what kind of RPG this game will be capable of, though, especially which battle system it will use (eg will it be versatile or just a single battle system, such as Reuben?)
*ahem*HBE?*ahem* I'm tempted to play with some C++ and try to build a battle background system like Earthbound. Totally unrelated to any work we should do beforehand but so fun to do....
I wonder if integrating HBE into WalrusRPG would be possible? Is the code vastly different (if any)? I'm still curious about what battle engine Streetwalrus wants, though. At first, it was Pokémon, since WalrusRPG was basically Pokéspire, but maybe it would not be suitable for a game like Illusiat or something.
I'd probably redo it from scratch, it's my hobby tovstart it from scratch again and again.
As you know, perfect is the enemy of good. Especially for professional computer programmers, because the real world is very different from the hobbyist world...
As a hobbyist, I've spent (lots of) time on things I'd basically never do as a professional programmer because the cost / benefit ratio is, um, dubious.
In the real world, there's basically never enough money to do things correctly. Especially in game development: bugs galore in most modern games, be them commercial or not.
While totally unsatisfying to the mind and counter-productive for the betterment of mankind, the cold, hard truth is that inferior, half-baked, insecure but timely and well-marketed crap wins against better but later / badly marketed stuff.
We're definitely not going to make this half-assed. We're aiming for quality but not necessarily perfection though. Thing is, since we started from scratch we need to scale our development environment, which is why we decided to switch from C to C++, and also why I reorganized the repo twice and completely overhauled the build system. If we didn't do that we'd be stuck way behind what we have now.
Quote from: Duke "Tape" Eiyeron on July 21, 2015, 08:05:02 AM
I'd probably redo it from scratch, it's my hobby tovstart it from scratch again and again.
I definitively recommend avoiding restarting stuff over and over, unless a version is completely broken. Else you eventually lose motivation because of how long it takes to progress and then your project ends up suffering the same fate as many older TI community projects from the past and more recent ones like E:SoR.
This is also why projects requires proper planning and that if restarting from scratch is necessary despite good planning, then it should be done as early as possible into development. I think some projects were restarted from scratch 90% into completion before.
Quote from: Lionel Debroux on July 21, 2015, 08:23:37 AM
As you know, perfect is the enemy of good. Especially for professional computer programmers, because the real world is very different from the hobbyist world...
As a hobbyist, I've spent (lots of) time on things I'd basically never do as a professional programmer because the cost / benefit ratio is, um, dubious.
In the real world, there's basically never enough money to do things correctly. Especially in game development: bugs galore in most modern games, be them commercial or not.
While totally unsatisfying to the mind and counter-productive for the betterment of mankind, the cold, hard truth is that inferior, half-baked, insecure but timely and well-marketed crap wins against better but later / badly marketed stuff.
So thats why a lot of modern things seem cty programmed <_<
Quote from: DJ Omnimaga on July 24, 2015, 05:11:30 AM
Quote from: Duke "Tape" Eiyeron on July 21, 2015, 08:05:02 AM
I'd probably redo it from scratch, it's my hobby tovstart it from scratch again and again.
I definitively recommend avoiding restarting stuff over and over, unless a version is completely broken. Else you eventually lose motivation because of how long it takes to progress and then your project ends up suffering the same fate as many older TI community projects from the past and more recent ones like E:SoR.
This is also why projects requires proper planning and that if restarting from scratch is necessary despite good planning, then it should be done as early as possible into development. I think some projects were restarted from scratch 90% into completion before.
Well to integrate hbe into our engine it would need some big modifications anyway to take advantage of the design we laid out. I don't remember how far eiyo went with his C port of hbe, since it was originally in Axe.
IIRC no code has been written yet. Design seemed to be in planning stages from what I remember from the topic.
Actually the battle engine in C was more advanced than the Axe mockup, but the code was as ugly as Axe's.
Little update : I'm working on a game-centered file archive custom type, to pack files like maps, sprites or custom data. : PIAF (PIAF Is an Archive Format). I even went with doing a computer library in Python to read/write them to help us with setting the data system later.
Will you use some existing compression algorithm or will you make your own?
Each file will have its own compression with whatever you want. I'm going to list used compression algorithms, put an id for each of them and store said ID in the filetable entry. So, if you want to use zlib, RLE, or whatever you want, you just have to put your own ID. This is only to help uncompressing common files, I could add a "don't manage unknown IDs" and let the dev uncompress how he wants.
I see now. That's good I guess. :)
It is. I feel more natural with Python, that allows me to be a bit more flexible on computer-based stuff. Gotta do more calc stuff though.
So this is the current state of the project :
(http://www.commitstrip.com/wp-content/uploads/2015/08/Strip-Fondations-english.jpg)
I'm working on splitting platform specific code from the main source, the build system was already modified to support multiple platforms (it was trivial to do on the new build system), now I need to come up with decent abstraction interfaces and hopefully we will be able to make a PC (SDL or SFML) and a GameCube/Wii port, possibly Android if we can get a reasonable C++ environment running on it too (Android is very peculiar as far as native development goes since the API is in Java).
I assume you will repeat the process described in the comic every month now? :P
Just kidding :), I am amazed that you want to make a GC/Wii port, since I thought you didn't want to write games for them. It would be nice to see this engine or game run on multiple platforms, audience-wise. :)
Quote from: DJ Omnimaga on August 27, 2015, 12:32:28 AM
I am amazed that you want to make a GC/Wii port, since I thought you didn't want to write games for them.
Actually, I've been interested in writing homebrew for the GC ever since I modded mine, it's just that I never really got into it. Since the Wii is pretty much an upgraded GC and has the same homebrew environment it won't be hard to make it run on both (though I won't really be able to debug it on the Wii since I don't have one).
Also if I ever get an HP prime I'd probably be interested in porting to it.
Maybe Juju could help debugging the Wii port? And yeah it would be nice if you could get an HP Prime, since it has quite a lot of powers. Hopefully
@alexgt can arrange a deal with his parents to get the calc shipped to you since he talked about sending it to you before due to being broken (and you would just plug another screen to it)
That said, if you ever learn HP PPL, that could be a better option for such game since you could use the emulator with extra WAIT commands and I could test for speed on my calc.
Quote from: DJ Omnimaga on August 28, 2015, 06:25:12 AM
That said, if you ever learn HP PPL, that could be a better option for such game since you could use the emulator with extra WAIT commands and I could test for speed on my calc.
Yeah but no. We already have a pretty large code base in C++ (over 1500 lines) so we're not going to port it to PPL. :P
Ah sorry to hear, although I guess it's good that you got this much code done.
Alright, I think the engine is very close to being portable. Stay tuned. :D
That is awesome. How much has it progressed by the way? I am curious about which game elements still need to be done?
There hasn't been much progress with regard to the actual engine tbh. :P We're still only displaying a map with animated tiles, though there have been performance improvements.
Oh ok. Since you said the engine is close to being portable I assumed that it was nearing completition. :P
Alright, I think we're pretty much to the point where I can start porting it to sfml. I'll check it out tomorrow. There may be a bit or two that will require further attention but I think 99% of splitting platform-specific code is done.
Cool. Keep us updated :). Hopefully the engine runs on as many platforms as possible.
Yes I hope so too, we've also been thinking about actual game content and we have some pretty nice ideas already. Still needs a lot of thinking.
Good to hear. Is there a possibility of seeing an old game ported using this engine? That could be an idea for a smaller project to start up with.
Yeah of course, the engine structure is pretty flexible (right now it's more of a framework :P).
I'll just leave this here. :)
Wow very cool. Does this run on the Nspire or computer? Also are those premade graphics or did one of you make them?
I hope that WalrusRPG will run on my calc, because it seems half-bricked D: (it can't run many Ndless programs and even Ndless 3.1 itself would no longer install)
That's a fully native PC port. The graphics are still the same placeholders from opengameart though.
And yeah we need to take some time together to fix up your calc.
Ooh nice. By the way will it be possible to run the game in scaled up (not stretched tho) full screen on computers? It would be nice since it would be like playing SNES games.
Yeah I'll add scaling when I figure it out.
Cool to hear. At first I was gonna suggest a 320x240 mode, but on some graphic cards it would end up looking blurry. Hence why scaling to multiple resolutions (including ones with black bars) would be better. Good luck figuring out how to compile to Windows.
It's done now. So you can play the game full-screen and it actually looks great.
The entire game is finished?? :P Just kidding, glad to see full screen mode implemented. :)
Actually due to a bug in SFML, I can't enable full screen yet. I made the window 640x480 by default though.
YOu can still cheat with some WMs likfe XFCE (Alt-F11 : fake fullscreen)
Working on PIAF right now; I'm figuring a decent loading process. Also the best thing about c++ is genericity:
[coode]
template <typename T> T read_big_endian_value(void *ptr)
{
T result = 0;
uint8_t *data = (uint8_t *) ptr;
for (unsigned i = 0; i < sizeof(T); i++)
result |= data[i] << (8 * (sizeof(T) - 1 - i));
return result;
}
Putting a template here allows me to avoid having to manage n times the same code. :D Generic data loading for every platform, it's cool, nah?
Quote from: Duke "Tape" Eiyeron on September 11, 2015, 09:31:00 PM
YOu can still cheat with some WMs likfe XFCE (Alt-F11 : fake fullscreen)
In X11, fullscreen is just a flag on the window, unlike on Windows where there's a whole mechanism behind it that allows the app to get exclusive access to the GPU and input devices for performance and latency reasons. Linux allows direct driver access anyway so it doesn't matter, and OpenGL is likely implemented with direct rendering in drivers that support it, so you effectively get the same benefits without exclusive access.
Breaking news : I made PIAF work on PC on a simple test file. further tests should be done but it's pretty could that I could, without problems, parse the header and file_table. It just means that getting the data after then will be easy as just reading the file on the right place.
Quote from: Streetwalrus on September 11, 2015, 07:23:37 PM
Actually due to a bug in SFML, I can't enable full screen yet. I made the window 640x480 by default though.
If FS ever becomes a serious issue, you could always allow the player to set the window even larger than 640x480, such as 1280x960 and 960x720. Some games do that.
Glad to see you guys progress on this (http://i.imgur.com/bMuNMG2.gif) (http://img.codewalr.us/streetwalrii3.gif)
The window was resizable already. I figured out what I was doing wrong now so it's fullscreen by default.
Ah, good to hear :)
On theleft, a shader. In the right the program version. And yeah, the 60FPS indication doesn't lie.
Quote from: Duke "Tape" Eiyeron on September 17, 2015, 07:14:49 PM
On theleft, a shader. In the the program version. And yeah, the 60FPS indication doesn't .
I think you ate some words here. :P
It seems like Android keyboard was drunk today.
I like the result so far. Will those backgrounds be used as battle backgrounds or will they be for magic animations?
It's the battle engine backdrop, just like in Earthbound.
https://www.youtube.com/watch?v=nAmBIljqgR8
The battle system is planned to be similar to this as well.
*ahem*another HBE attempt*ahem*
AH ok, I was wondering since Eiyeron was already making an Earthbound-style engine. Will WRPG support standard backgrounds for other games?
Anyone is free to modify the engine. It's pretty much mandatory to do so anyway when you make games with a generic engine.
Quote from: Streetwalrus on September 18, 2015, 07:08:35 AM
Anyone is free to modify the engine. It's pretty much mandatory to do so anyway when you make games with a generic engine.
>generic
>ranting about having flexible tile size in maps.
:p
Lol, some parts are generic and some parts not.
If the engine has generic part, does it mean that they are inferior to Illusiat 1? :trollface:
Anyway, I am curious if you got battle menus and the like thought out or if HBE being used is now official?
Apparently Eiyeron is going to rewrite it from scratch but he's aiming for a similar feature set so yeah.
Ah I see. I wish him good luck. He should keep us updated in the HBE thread when he got what he already wrote rewritten :)
Well wrpg is pretty much a merge of HBE and Pokespire, starting from scratch (Pokespire didn't have much so we actually ported the existing code to C++).
Oh. But isn't HBE for more platforms including the 83+?
Does it mean I should make a sub-forum for both HBE and WRPG instead of keeping HBE material in its own?
First it was in Axe then he rewrote it in C. Don't do anything for now, WRPG is still a separate project.
Ok. Yeah I was wondering if he had ditched 84+ support. I know that it supports C but I heard it was very limited compared to other platforms.
This project is now indefinitely halted. Even though I'm still in touch with Eiyeron, we lost interest in it and we're moving on to new things.
This was our last calculator project, we're now aiming for less limited platforms to have a little more freedom and make programming fun again.
Sorry to disappoint anyone.
Why not Microcat? D:
An universal rpg engine for Microcat would be awesome! Anyway, if you are not the guys to do it, we can't force you :P
I actually have other things in the pipeline but for now it's a secret. I've started too many project threads without any going nowhere so now I'm not showing anything until I actually have something to show. :P
Ah I see. Just don't do like people on ticalc.org who only announces their stuff once it's 100% complete. It's best to get some feedback and also publicity on forums prior release :P
Yeah of course. But I'm waiting until I have something semi-decent to show (ie not just a tilemapper). :P
The update list is too long to bring it, but the game engine still evolves with my side-side-projects and my motivation to finish it. The undertale battle engine was done part because I wanted to make WRPG progress. Now, I'm also interested in 3DS Homebrew, so...
Glad to see this on the 3DS too. Did you manage to make new graphics and maps since the previous forum update?
I didn't because I'm still focused on the game engine's internals. Just added hibernation and correct timing support for the 3DS backend. The only regression I had to put is putting out the exceptions as they're not supported by the current devkit for this device. Gotta find a way to circumvent this.
Hm I see. Yeah I was wondering about graphics since it has been over a year since this engine started being worked on. :P But take your time. :)
What kind of system requirements does WRPG have? Would it be possible to port it to the GBA too?
Well, it'll probalby not fit it because of the memory requirement ( I don't have a clue of how much memory I'm asking but it'll be probably way over the GBA's capacities, alas.
Edit :
Quote from: DJ Omnimaga on April 18, 2016, 03:32:58 PM
Hm I see. Yeah I was wondering about graphics since it has been over a year since this engine started being worked on. :P But take your time. :)
I am taking it, don't worry. I can't run at my own pace as I'm living more and more attention troubles and the lack of support of the people already involved in it doesn't help at all.
What do you mean by "attention troubles"? Do you mean you are being busier with real life or do you mean that your attention span is decreasing over time?
Also for the latter thing, never make a project expecting you'll get any help, even if you have team members. In 99.9% of the cases team projects always end up with just 1 person doing the entire work in the end. That's what I learned in the past 17 years I've been online. Always work on projects as if you were alone to work on it (in other words, don't take the help of others for granted, else the project will die from waiting)
I always more or less did my projects solo, only asking sometimes for help on some topics. When I was given the possibility to make a project with someone else, and when I see that I'm basically making it alone since a few months... :|
Also, yeah, my attention span is ridiculously small these months, if not years. I hardly progress in any of my projects and constantly switch over all of them.
(http://i.imgur.com/rJa4sBv.png)
Map loading system in progress. The cursious checkerboard is normal : Tiled offsets every tile id by one, and as the orignal map just didn't use a tile as filler for the exterior, it just stored the blank tiles as 0, which means this checkerboard tile.
EDit : (https://pbs.twimg.com/media/CggsP97WwAA_w6M.jpg:large)
That looks excellent! :D
Quote from: Duke "Tape" Eiyeron on April 20, 2016, 02:27:46 PMAlso, yeah, my attention span is ridiculously small these months, if not years. I hardly progress in any of my projects and constantly switch over all of them.
I kinda became like that over the years, since my attention span towards programming isn't as big as a few years ago. When I started working on Opossum Massage Simulator, I started two other projects before finishing it and two others went in planning stages or started being considered. I also have plenty of other projects that have been on hold for years. >.<
Quote from: Duke "Tape" Eiyeron on April 20, 2016, 07:45:13 PM
(http://i.imgur.com/rJa4sBv.png)
Map loading system in progress. The cursious checkerboard is normal : Tiled offsets every tile id by one, and as the orignal map just didn't use a tile as filler for the exterior, it just stored the blank tiles as 0, which means this checkerboard tile.
EDit : (https://pbs.twimg.com/media/CggsP97WwAA_w6M.jpg:large)
This looks walriific! Good job so far. :)
3DS support is now official (it's in the main/master source code branch) and next will be the resource manager (to avoid opening/closing/opening/closing files on the fly).
Got a little planning of what should be done (in this order, more or less):
- Work should be done on some things like the font system (which right now doesn't have a version check) and some exception stuff (making all WRPG exceptions implements a common interface and adding exceptions where they're lacking).
- Work on the tilemap, to allow loading tile data in the same time than the map. It'll be nice for later to support animated tiles, collision data and which texture to load as spritesheet.
- Add a template PC to allow interacting with the map (while adding collision stuff). It'll be cool for the next step.
- Thinking on the event system and eventually the entity system could be tought on later.
'm still wondering how I can support NPCs (which are moving entities with/without a script to move or stuff), from interactive objects (like chest and levers), their variables (like local/global events, local for map and save -based conditions, global for save-based conditions) and interacting with them.
Edit : I'm so going to have fun when I'll also have to support sound on platforms which can make noise. Between the 3DS which have a low-end DSP inteface and SFML which is high-ended and my desire to use XM files for musics...
Will 3DS have some touchscreen controls for the menu or will it be the same version as the others? Also wasn't the 3DS screens less than 240 pixels in height? I forgot.
Also good luck with NPC's
Quote from: DJ Omnimaga on April 25, 2016, 12:23:01 AM
Will 3DS have some touchscreen controls for the menu or will it be the same version as the others? Also wasn't the 3DS screens less than 240 pixels in height? I forgot.
Also good luck with NPC's
Same version, I don't plan any touchscreen controls/features for now. Also, the 3DS is 400*240 (800 if we count both screens).
ALso thanks.
Ah I see. I thought it was more like 192 pixels in height or maybe 200-212. And that's fine. At least I'm happy it's 3DS-compatible since if a game comes out of this then it will reach a much larger audience. I am curious about what are the RAM requirements? Would 256 KB be enough?
libxmp ( https://github.com/cmatsuoka/libxmp ) can render tracks to sound and output sound through multiple backends. You probably already know about that library, or similar, older and more unsafe ones, but I thought I'd mention libxmp anyway :)
The standard/full version of libxmp handles all kinds of uncommon formats; the lite version handles the four most popular formats: S3M, MOD, XM and IT.
Quote from: DJ Omnimaga on April 25, 2016, 04:50:34 AM
Would 256 KB be enough?
To make it fit on the newer Ti-83 color models? Obviously not. For instance this demo has, IIRC, three textures, one of 256x256 pixels (the spritesheet, with 16-bits, once decompressed weights a whole 128KB), a 132*81 (the variable size font ~10KB) and another one, wieghting 32KB (the monospace debug font).
The map? 26*26*16bits (so 2 bytes) = 1352 bytes (more than 1KB). Okay, it's honnest. Move along.
The font data (not the spritesheet) : 3.1KB.
But I can't know the whole structure wieghts. I guess it's pretty heavy as it has a smaller STL replacement allowing unordered_map and vector to be used without adding 800KB to the binary when uncompressed.
Well, it's lighter than expected but it doesn't have half of the features I want. I guess it could fit for light maps and stuff, but don't expect to have a decent framerate on such smaller calc, specially when I have to tell you than with the map, textbox and some misc stuff, we quickly are reaching under the 60 fps cap because of the slowness of the memory.
Quote from: Lionel Debroux on April 25, 2016, 05:18:17 AM
libxmp ( https://github.com/cmatsuoka/libxmp ) can render tracks to sound and output sound through multiple backends. You probably already know about that library, or similar, older and more unsafe ones, but I thought I'd mention libxmp anyway :)
The standard/full version of libxmp handles all kinds of uncommon formats; the lite version handles the four most popular formats: S3M, MOD, XM and IT.
Thanks for the suggestion, I'm going to check if it 's lighter than Dumb (https://github.com/kode54/dumb/tree/master/dumb). It works but it has stuttering on heaver XM files.
Edit : mmmh, the LGPL is pushing a constraint on the source code but as long as I don't edit libxmp, it should be fine.Edit 2 : DIdn't saw the lite version with MIT licence.
Edit 3 : a proof-of-concept prototype of a XM player works with libxmp-lite now. It's way better than wit hDUMB and I don't get any stuttering, even with smaller and less numerous buffers.
Aw too bad. I was wondering since the 83pCE is much more popular than the Nspire CX. It's ok, though. Maybe once this is finished, someone could fork it and make a downgraded version for the CE.
Well, I do think it'll be better to start from zero as it'll be easier to cut off unneeded features or put restricts on the system (for instance only one font for stuff, no logging or stuff)
On the CE I think an elaborate engine would be doable, it would be just a matter of having to load more data in real-time due to smaller amounts of RAM to cache it. Map walking would probably need to either get rid of scrolling or have movement be tile by tile rather than smooth.
That said, if a new engine was made for lower-end platforms, it would still be nice if it was compatible with the bigger engine, so that people could easily work on smaller RPGs for the CE and Nspire simultaneously.
Fellows, I'll need a testing volunteer to dumb-test compilation on Windows from scratch, if anyone (preferably having Telegram) feels up to it, please contact me by PM here or on twitter (my nickname is my handle) PM. Thanks in advance.
It would probably depend how difficult and tedious it is to setup a compiling environment and if it's Windows 7 compatible for me.
On a side note, now that I look at those graphics full-size, they truly reminds me of ActRaiser world map. :P
I'd like to follow someone from zero to compilation, so yeah, it may not be easy.
Well obviously the engine can't be ported to the TI-83 CE because the C++ library alone
takes the entire memory.
See ?
Butt Cee iz baaaadds, c++ roks !!!
shut up.
I can test on Wine and compile with Mingw, if that's ok...
(also a SDL1.2/SDL2 backend would be nice)
Quote from: gameblabla link=topic=24.msg37345#msg37345
See ?
Butt Cee iz baaaadds, c++ roks !!!
shut up.
Are those three lines meant to be a conversational quote or just one or two of them?
Also yeah I doubt I'll be able to test compiling then. Just timezone and my work schedule alone would make it impossible to be online both at the same time often enough.
Quote from: gameblabla on April 28, 2016, 03:12:18 PM
Well obviously the engine can't be ported to the TI-83 CE because the C++ library alone
takes the entire memory.
See ?
Butt Cee iz baaaadds, c++ roks !!!
shut up.
I can test on Wine and compile with Mingw, if that's ok...
(also a SDL1.2/SDL2 backend would be nice)
Also I don't see the point to SDL target where we have the SFML which does what we want.
And we don't use libstdc++ as said earlier because of the program size problem. It wouldn't have brought enough for the footprint it added over the program.
Welp, I don't what changed since but I'll try :
- Entity-Entity and Entity-Map collision (cing finally done it right), needs grid/quadtree to avoid killing performances if there are too many entities.
- Tilemaps are now on three layers : the ground (collision-enabled), the middle where things can overlap or be overlapped by entities (collision-enabled) and over layer which will overlap every entities
- A better example state is in the works with interactive entities and some text appearing on screen.
- Better time handling, moved to a fixed timestep system (change to be merged in master)
- Fixed some things
- Better file handling
- An alternate and private project made me progress and fix some things for the textbox (like new command codes and fixed the coloration)
- Changed the panic exit combo key to ZL+ZR on n3DS (Use HBL's L+R+Down+B combo for original 3DS for now)
- Added smdh generation for 3DS (no icon yet)
Is the over-layer for stuff like fog, forest and clouds? Nice to see updates :)